Re: [PATCH] Updated: Dynamic Tick version 050408-1

[Thomas Renninger <trenn@suse.de>]

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