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.




-----Original Message-----
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
ext Ivan Khoronzhuk
Sent: Thursday, September 03, 2015 12:11 AM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [odp-lng] [Patch v3 1/3] api: time: unbind CPU
cycles from time API

Current time API supposes that frequency of counter is equal
to CPU frequency. But that's not always true, for instance,
in case if no access to CPU cycle counter, another hi-resolution
timer can be used, and it`s rate can be different from CPU
rate. There is no big difference in which cycles to measure
time, the better hi-resolution timer the better measurements.
So, unbind CPU cycle counter from time API by eliminating word
"cycle" as it's believed to be used with CPU.

Also add new opaque type for time odp_time_t, as it asks user to use
API and abstracts time from units. New odp_time_t requires several
additional API functions to be added:

odp_time_t odp_time_sum(odp_time_t t1, odp_time_t t2);
int odp_time_cmp(odp_time_t t1, odp_time_t t2);
uint64_t odp_time_to_u64(odp_time_t hdl);

Also added new definition that represents 0 ticks for time -
ODP_TIME_NULL. It can be used instead of odp_time_from_ns(0) for
comparison and initialization.

This patch only changes used time API, it doesn't change used var
names for simplicity.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronz...@linaro.org>
---





  /*
diff --git a/test/performance/odp_scheduling.c
b/test/performance/odp_scheduling.c
index 2a7e531..5859460 100644
--- a/test/performance/odp_scheduling.c
+++ b/test/performance/odp_scheduling.c
@@ -183,9 +183,10 @@ static int test_alloc_single(int thr, odp_pool_t
pool)
  {
      int i;
      odp_buffer_t temp_buf;
-    uint64_t t1, t2, cycles, ns;
+    odp_time_t t1, t2, cycles;
+    uint64_t ns;

-    t1 = odp_time_cycles();
+    t1 = odp_time();

      for (i = 0; i < ALLOC_ROUNDS; i++) {
          temp_buf = odp_buffer_alloc(pool);
@@ -198,12 +199,12 @@ static int test_alloc_single(int thr, odp_pool_t
pool)
          odp_buffer_free(temp_buf);
      }

-    t2     = odp_time_cycles();
-    cycles = odp_time_diff_cycles(t1, t2);
-    ns     = odp_time_cycles_to_ns(cycles);
+    t2     = odp_time();
+    cycles = odp_time_diff(t1, t2);
+    ns     = odp_time_to_ns(cycles);

      printf("  [%i] alloc_sng alloc+free   %"PRIu64" cycles, %"PRIu64"
ns\n",
-           thr, cycles/ALLOC_ROUNDS, ns/ALLOC_ROUNDS);
+           thr, odp_time_to_u64(cycles) / ALLOC_ROUNDS, ns /
ALLOC_ROUNDS);

      return 0;

For example, this is really measuring average CPU cycles (with or without freq 
scaling). The ns conversion can be removed.

-Petri






--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to