Re: [PATCH] Dynamic tick for x86 version 050609-2

[Thomas Renninger]

Valdis.Kletnieks@xxxxxx wrote:
> On Mon, 13 Jun 2005 08:25:07 PDT, Tony Lindgren said:
> 
>>You may also want to check out the patch by Thomas Renninger for ACPI
>>C-states. I've added a link to it at:
>>
>>http://muru.com/dyntick/
> 
> I think that's muru.com/linux/dyntick ?
> 
> I'm not sure what Thomas's patch will do for me
Not much.
The one measures how long your machine really stays in
each C-state (Tony's pmstats should be sufficient for you).

The other one tried to calc the next C-state to go, based on
statistics of bus master activity and idleness of the machine.
But it is *wrong*.
Tony could you please remove the link to:
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/dynamic_tick_cstate_patch.diff
Therefore we also will never get such good results as stated in:
ftp://ftp.suse.com/pub/people/trenn/dyn_tick_c_states/measures_C4_machine

The problem is that if there is bus master activity, a certain amount of time
has to be waited (nobody could tell me how long this must be, currently
it's 40 ms. Then it's assumed bm transfers have been finished) before C3/C4 can be called ->
-> bm activity is not interrupt driven -> this needs ticks to be enabled.

Therefore a final patch could look like:
Let ticks be enabled (maybe reduced?) as long as machine is still in C1/C2 and
only disable them for deeper sleeping states (C3/C4).

 - here's what I currently have:
> 
> % cat /proc/acpi/processor/CPU0/power 
> active state:            C2
> max_cstate:              C8
> bus master activity:     00000000
> states:
>     C1:                  type[C1] promotion[C2] demotion[--] latency[000] usage[00000010]
>    *C2:                  type[C2] promotion[--] demotion[C1] latency[050] usage[01314979]
> 
> Near as I can tell, we start off in C1, drop into C2, and stay there no
> matter what happens - we never move back up to C1, and there's no C3 to drop
> into....
> 
> Should there be a C3/C4?  Is my laptop just plain borked? :)
Depends on your machine and BIOS, whether it's supported -> seems as if it's not.

You could verify by having a deeper look in your FADT/DSDT.
You need the acpi tools from Len Brown (acpidmp/acpixtract) and the iasl Intel ACPI
compiler.
AFAIK checking for C-support is rather robust in recent kernels as long as you don't have a broken
DSDT table.
Maybe you find a newer BIOS supporting C3?

To be honest, I doubt you save much power even with dyn tick enabled if you only have support
for C1 and C2. The pmstats tool from Tony (see link above)
could tell you nicely whether you gain anything.


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