Re: [PATCH 86/98] ACPI: cap off P-state transition latency from buggy BIOSes

Len Brown
2009-04-07T05:48:42Z

thanks,
Len Brown, Intel Open Source Technology Center

On Mon, 6 Apr 2009, Thomas Renninger wrote:

> On Friday 03 April 2009 06:35:20 pm Len Brown wrote:
> > > Whatabout:
> > >
> > > CC: stable@kernel.org
> >
> > I've added this to my .stable list, thanks for pointing it out.
> > Note that I don't send patches to stable until after they are upstream.
> Thanks.
> There are generally two kind of patches that should go to stable:
> 1) The simple NULL pointer fixes (and similar safe ones) which can/
> should go directly to stable, at least if they hit the mainline kernel
> 2) Bug fixes which potentially could harm others (as you mentioned
> in the other one).
> For the latter these should go to stable if they survived a full mainline kernel
> round (and eventually together with add-on patches) or at least some RCs.
> Looks like every maintainer has his own way (and overhead) to queue and
> take care of them?
> I wonder how things could get automated and patches could get tagged,
> not only with CC: <stable@kernel.org>, but to consider both cases.
> Or you always add CC: <stable@kernel.org>, the stable team will ask again
> before adding them and you can tell them to still hold them off for a while,
> so that they get more testing.

I send patches to stable manually,
and I manually make sure it applies to the targeted .y release first.

As you know, I'm not super aggressive in what I send back,
but I do keep a list for this in my notes.

> > > This is a bug fix also existing in older kernels.
> > > I remember even much newer HW (Intel and AMD) based have higher values
> > > exported through ACPI _PSS tables as latency.
> > >
> > > I remember values around (50-70us Core 2 Duo?) and 37us on K10.
> > > I doubt this patch will cause much pain, but being close to values
> > > exported via ACPI tables on similar HW sounds like a good idea.
> > >
> > > In 2.6.30 (as soon as cpufreq branch is merged) you get that easily from
> > > here:
> > > cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
> > > 109000
> > >
> > > I expect my machine's (K8 Dual core) ACPI exported value will be cut down
> > > to:
> > > 20000
> > > now?
> >
> > Does your AMD box run acpi-cpufreq and use native MSR access to change
> > P-states?

> Argh, now I see it. It's done in acpi-cpufreq, it looked like generic code in
> drivers/acpi/processor_*
>
> But it still looks rather low. I've seen higher values exported
> via ACPI tables even for newer Intel based laptops. But Venki should
> know better than myself. Just a heads up.

We (Intel Linux team) are acutely aware of Intel's actual P-state
latencies and how BIOS writers are more often wrong than right.

note that this cap applies only to the systems that support
MSR transitions -- which is the newer stuff.

> Capping off the sampling rate generally (this is the value calculated from the latency
> which causes the performance regression) in ondemand governor to e.g. 100ms sampling rate
> is probably also a good idea. I'll suggest that on the cpufreq list...

yeah, that does sound like a good idea.
all it needs is a real example of the failure to justify the patch.

cheers,
Len Brown, Intel Open Source Technology Center