Tony Lindgren wrote: > * Thomas Renninger <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/