Petri,
On 04.09.15 12:14, Savolainen, Petri (Nokia - FI/Espoo) wrote:
-----Original Message-----
From: ext Ivan Khoronzhuk [mailto:ivan.khoronz...@linaro.org]
Sent: Thursday, September 03, 2015 6:26 PM
To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [odp-lng] [Patch v3 1/3] api: time: unbind CPU
cycles from time API
Petri,
On 03.09.15 16:13, Ivan Khoronzhuk wrote:
On 03.09.15 15:29, Savolainen, Petri (Nokia - FI/Espoo) wrote:
There are many example apps that actually want to measure execution
time in CPU cycles, not in nsec.
Time API and CPU (cycle) API updates are linked together. Real CPU
cycle cases must not converted to use time API, but to use a new
odp_cpu_cycle() count API first.
Then what is left should be actual time API use cases.
Let me look at CPU API first.
I hesitate to answer because of freq scaling. I have filling that
there is not so very well.
And yes, probably I should move part of this changes in preparation
series.
where did you see, odp_cycle_count?
Even if you are going to add. Think once again.
It seems it's better replace it here on odp_time.
Imagine the system which has cpufreq governor that dependently on
packet rate,
and hence system load, regulate CPU frequency in order to reduce power
consumption.
In this case you CPU rate is changing very fast and frequently.
When you get frequency with odp_cpu_hz() it doesn't mean that this freq
was
the same a 1ms ago or 1ms after.
Or
What if we have frequency spectrum: F1 F2 F3 Fmax
Fmax can be switched on in rarely cases when traffic rate is extremely
hi.
This period is very short and most time (99%) CPU is working at F3, as
processor can
be damaged by temperature. In some point in time odp_cpu_hz() can
return Fmax.
But you want to count some number of cycles in period of time, mostly
with freq = F3.
But you got Fmax, your calculation will be wrong. In this regard
current cpu frequency API looks very pure.
And by a big account it should be calculated in combine with governor,
which can be absent
or even in operating system.
Seems we don't have a choice, and should use odp_time for that.
cpu cycles count can be evaluated only by
odp_time()*odp_cpu_hz()/odp_time_hz().
But I'm worry about how we can count some cpu cycles if we are not sure
in cpu frequency :-|?
It's not informative for systems in question.
So better to evaluate it with odp_time. No choice.
CPU cycle measurement is different from time (latency) measurement. CPU cycle
count tells you exact CPU overhead. These tests measure CPU overhead, which is
many times more relevant for performance measurement than latency (nsec).
User can choose the governor policy and interpret the measurement results
accordingly.
I'm going to add cpu cycle functions into cpu.h.
No objection. It be good you add it in near future.
And don't forget to mention that it's valid only in debug purposes.
Also it can be 32-bit counter and it can wrap (4s), so it should be close to
time api.
And create maybe some ticket I can point that it blocks me to add time API.
-Petri
--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
