On Sat, Jul 23, 2011 at 11:49:37PM -0400, Matthew Garrett wrote: > > This way may give the benefit of making it work per core instead of > > per package. The manual is rather unclear on this point. > > Being able to enter turbo mode typically requires coordination between > the cores in order to ensure that the package remains within limits. The > AMD implementation certainly disables their equivalent entirely if any > core in the package has it disabled. I haven't verified that Intel > behaviour is identical, but it wouldn't surprise me. I can try to check > that. We actually can do both on family 12h - per core and per package disable. Family 10h, revE does only per-package disable. We opted for having a single interface for sw and always do per-package disable simply because we have no usecases for per-core disable and I agree with Matthew - we'll implement it only when it's needed. > > I actually have a use case for this. I have a system that keeps a > > bunch of cores under moderate load. I have one thread in particular > > that needs to be fast, and I'd like to disable boosting on the other > > cores to keep more thermal and power headroom available for the one > > thread that cares. > > Are the other threads sufficiently opportunistic to use extra CPU power > if it's available to them? You'll generally only get turbo if the other > cores are in C6, so even if turbo is disabled on a specific core it'll > probably prevent another core from entering turbo if anything's > executing on it. You'd arguably want it to be able to get into turbo so > it can hit C6 more quickly and let the other thread use the extra > headroom. Right, so we were looking for per-core disable use cases too while discussing this internally. Andy, limiting the other cores to a higher P-state (lower freq) and letting the one core boost with a higher headroom might actually give you more bang than turning off boost on the n-1 cores. This definitely needs some experimenting and measurements before you can say for sure. And it all depends on the specific workload and boosting algorithm. There's this cpufreq-aperf tool in cpufrequtils which shows you the boosted freq and C-state residency of the cores, or <tools/power/x86/turbostat/> in the kernel sources - you might wanna do some measurements with those to actually have some hard data for your workload ... HTH. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
