lkml.org 
[lkml]   [2016]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH V2] cpuidle: Change ktime_get() with local_clock()
From
On Thu, Apr 21, 2016 at 10:56 AM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> The ktime_get() can have a non negligeable overhead, use local_clock()
> instead.
>
> In order to test the difference between ktime_get() and local_clock(),
> a quick hack has been added to trigger, via debugfs, 10000 times a
> call to ktime_get() and local_clock() and measure the elapsed time.
>
> Then the average value, the min and max is computed for each call.
>
> From userspace, the test above was called 100 times every 2 seconds.
>
> So, ktime_get() and local_clock() have been called 1000000 times in
> total.
>
> The results are:
>
> ktime_get():
> ============
> * average: 101 ns (stddev: 27.4)
> * maximum: 38313 ns
> * minimum: 65 ns
>
> local_clock():
> ==============
> * average: 60 ns (stddev: 9.8)
> * maximum: 13487 ns
> * minimum: 46 ns
>
> The local_clock() is faster and more stable.
>
> Even if it is a drop in the ocean, changing the ktime_get() by the
> local_clock() allows to save 80ns at idle time (entry + exit). And
> in some circumstances, especially when there are several CPUs racing
> for the clock access, we save tens of microseconds.
>
> The idle duration resulting from a diff is converted from nanosec to
> microsec. This could be done with integer division (div 1000) - which is
> an expensive operation or by 10 bits shifting (div 1024) - which is fast
> but unprecise.
>
> The following table gives some results at the limits.
>
> ------------------------------------------
> | nsec | div(1000) | div(1024) |
> ------------------------------------------
> | 1e3 | 1 usec | 976 nsec |
> ------------------------------------------
> | 1e6 | 1000 usec | 976 usec |
> ------------------------------------------
> | 1e9 | 1000000 usec | 976562 usec |
> ------------------------------------------
>
> There is a linear deviation of 2.34%. This loss of precision is acceptable
> in the context of the resulting diff which is used for statistics. These
> ones are processed to guess estimate an approximation of the duration of the
> next idle period which ends up into an idle state selection. The selection
> criteria takes into account the next duration based on large intervals,
> represented by the idle state's target residency.
>
> The 2^10 division is enough because the approximation regarding the 1e3
> division is lost in all the approximations done for the next idle duration
> computation.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>

Looks good to me.

Peter, are you happy with the changelog now?

\
 
 \ /
  Last update: 2016-04-21 22:01    [W:0.075 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site