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

[Tony Lindgren <tony@atomide.com>]

* Thomas Renninger <trenn@suse.de> [050613 11:01]:
> Valdis.Kletnieks@vt.edu 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 ?

Oops, that's correct.

> > 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

OK, removed.

> 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.

Yes, the savings are hard to get currently. In the long run using C4 and
idling some devices when the ticks to skip is longer should give better
savings.

Tony
-
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/