[lkml]   [2005]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Updated: Dynamic Tick version 050408-1
* Thomas Renninger <> [050408 04:34]:
> Here are some figures about idle/C-states:
> Passing bm_history=0xF to processor module makes it going into C3 and deeper.
> Passing lower values, deeper states are reached more often, but system could freeze:

Hmm, I wonder why it freezes? Is it ACPI issue or related to dyn-tick?

> Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms)
> Total switches between C-states: 20205
> Switches between C-states per second: 1063 per second
> Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000:
> Total switches between C-states: 4659
> Switches between C-states per second: 65 per second

The reduction in C state changes should produce some power savings,
assuming the C states do something...

> I buffer C-state times in an array and write them to /dev/cstX.
> From there I calc the stats from userspace.
> Tony: If you like I can send you the patch and dump prog for
> ?

Yeah, that would nice to have!

> I try to find a better algorithm (directly adjust slept time to
> C-state latency or something) for NO_IDLE_HZ (hints are very welcome)
> and try to come up with new figures soon.

I suggest we modify idle so we can call it with the estimated sleep
length in usecs. Then the idle loop can directly decide when to go to
C2 or C3 depening on the estimated sleep length.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-08 13:59    [W:0.126 / U:17.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site