lkml.org 
[lkml]   [2005]   [Apr]   [8]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 08 Apr 2005 14:58:50 +0200
FromThomas Renninger <>
SubjectRe: [PATCH] Updated: Dynamic Tick version 050408-1
Tony Lindgren wrote:
> * Thomas Renninger <trenn@suse.de> [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?
> 
It's an ACPI issue.
As far as I understand: If there has been bus master activity in the last
xx(~30?!?) ms, C3 and deeper sleep states must not be triggered.
If running into it, the system just freezes without any further output
or response.

>>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 heard on this machine battery lasts half an hour longer since
C4 state is used, hopefully we can get some more minutes by using it
more often and longer ...

>>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
>>http://www.muru.com/linux/dyntick/ ?> > Yeah, that would nice to have!

-> I'll send you privately.
> >>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.

The sleep time history could be enough?

I don't know how to calc C1 state sleep time (from drivers/acpi/processor_idle.c):
		/*
                 * TBD: Can't get time duration while in C1, as resumes
		 *      go to an ISR rather than here.  Need to instrument
		 *      base interrupt handler.
		 */
It probably would help to go to deeper states faster.

Whatabout reprogramming timer interrupt for C1 (latency==0), so that it comes out after e.g. 1 ms again.
If it really stayed sleeping for 1ms, 5 times, the machine is really idle and deeper
states are adjusted after sleep time and C-state latency...
(Or only disable timer interrupt after C1 slept long enough X times?)

      Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-08 13:04    [from the cache]
©2003-2008