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@xxxxxxxxxx > > > > 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@xxxxxxxxxx>, but to consider both cases. > Or you always add CC: <stable@xxxxxxxxxx>, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
