lkml.org 
[lkml]   [2010]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] [PATCH] timer: Added usleep[_range][_interruptable] timer
From
Date
On Mon, 2010-06-28 at 11:03 -0700, Patrick Pannuto wrote:

> Well here we go then.

Great.


> *** RESULTS ***
>
> Complete results are attached (please forgive the ugly stats.py, it
> evolved; it's functional for the task at hand, but certainly not pretty).
>
> --> Long results also at end of email
>
> From the final results, after 240s:
>
> TIME STATE #TIMES CALLED TIME IN STATE | DELTA FROM ORG
>
> ////////////////////////////////////////////////////////////////////////////////
> === origin (10 samples) =================================== RUNTIME: 241.535 ===

What's the 10 samples here?

> 240 idle-spin -- 2.3 1.45001e-05
> 240 not-idle -- 88368.2 67.8311703321
> 240 idle-request -- 88367.2 23337.6322655
> 240 idle-wfi -- 88364.9 172.296383696

I'm going to assume you did ten in "origin" (i.e. control runs) and
averaged. However, you need to explicitly say that ..

What units is "time in state", and what interfacing does the timing? Are
these states in order from least power saving to most power savings?

> === over1000 (10 samples) ====== (delta: -0.00999999998604) RUNTIME: 241.525 ===
> 240 idle-spin -- 3.1 1.91666e-05 | 4.6665e-06
> 240 not-idle -- 88723.9 65.6361809172 | -2.1949894149
> 240 idle-request -- 88722.9 23311.9855603 | -25.6467051707
> 240 idle-wfi -- 88719.8 174.493487111 | 2.1971034149
> === over500 (10 samples) ======== (delta: -0.0339999999851) RUNTIME: 241.501 ===
> 240 idle-spin -- 2.3 1.88334e-05 | 4.3333e-06
> 240 not-idle -- 88636.3 67.0242803241 | -0.806890008
> 240 idle-request -- 88635.3 23280.1632631 | -57.469002442
> 240 idle-wfi -- 88633.0 173.077055869 | 0.7806721723
> === over100 (10 samples) ======== (delta: -0.0539999999921) RUNTIME: 241.481 ===
> 240 idle-spin -- 0.9 6.6666e-06 | -7.8335e-06
> 240 not-idle -- 88599.0 67.190273164 | -0.6408971681
> 240 idle-request -- 88597.9 23253.4797828 | -84.1524827638
> 240 idle-wfi -- 88597.0 172.884529866 | 0.5881461694
> === equal100 (10 samples) ================== (delta: -0.025) RUNTIME: 241.51 ===
> 240 idle-spin -- 1.4 9.5002e-06 | -4.9999e-06
> 240 not-idle -- 88685.9 66.5067348407 | -1.3244354914
> 240 idle-request -- 88684.9 23294.4341497 | -43.1981158192
> 240 idle-wfi -- 88683.5 173.60379269 | 1.3074089936
> === equal50 (10 samples) ======== (delta: -0.0289999999804) RUNTIME: 241.506 ===
> 240 idle-spin -- 2.0 9.6664e-06 | -4.8337e-06
> 240 not-idle -- 88537.4 65.8619214556 | -1.9692488765
> 240 idle-request -- 88536.4 22979.3665406 | -358.265724952
> 240 idle-wfi -- 88534.4 174.247270576 | 1.9508868794
>
>
> There appears to be very little change outside of noise from origin through
> equal100, however, once equal50 is reached, there is a noticeable change.

it all looks pretty noisy still, but it could be that your just
providing too much information ...

Ok, so the idle-request state had residency of 22979us (guessing units)
in equal50, and 23338us in the control. Which is %1.5 less. I would
think you want more residency rather than less right?

Replacing 50us udelays with timers will cause more timers to trigger at
a high frequency, which would cause you to be running timer code more
often rather than doing something else (maybe being in a sleep state).
So the number make some sense.

Does over100 include everything from 100 to 1000 ?

Daniel



\
 
 \ /
  Last update: 2010-06-28 21:41    [from the cache]
©2003-2011 Jasper Spaans