linux-kernel - Re: [PATCH v4 3/7] acpi-cpufreq: Add support for disabling dynamic overclocking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110724093614.GA9391@aftab>
Date:	Sun, 24 Jul 2011 11:36:14 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Andrew Lutomirski <luto@....edu>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"davej@...hat.com" <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Langsdorf, Mark" <mark.langsdorf@....com>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>
Subject: Re: [PATCH v4 3/7] acpi-cpufreq: Add support for disabling dynamic
 overclocking

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/