From: Borislav Petkov <bp@amd64.org>
To: Matthew Garrett <mjg@redhat.com>
Cc: Andrew Lutomirski <luto@mit.edu>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
"davej@redhat.com" <davej@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Langsdorf, Mark" <mark.langsdorf@amd.com>,
"Herrmann3, Andreas" <Andreas.Herrmann3@amd.com>
Subject: Re: [PATCH v4 3/7] acpi-cpufreq: Add support for disabling dynamic overclocking
Date: Sun, 24 Jul 2011 11:36:14 +0200 [thread overview]
Message-ID: <20110724093614.GA9391@aftab> (raw)
In-Reply-To: <20110724034937.GA25873@srcf.ucam.org>
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
next prev parent reply other threads:[~2011-07-24 9:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 16:37 [PATCH v4] Move modern AMD cpufreq support to acpi-cpufreq Matthew Garrett
2011-07-18 16:37 ` [PATCH v4 1/7] x86: Add AMD HW_PSTATE cpu feature bit and MSRs Matthew Garrett
2011-07-18 16:37 ` [PATCH v4 2/7] acpi-cpufreq: Add support for modern AMD CPUs Matthew Garrett
2011-07-18 16:37 ` [PATCH v4 3/7] acpi-cpufreq: Add support for disabling dynamic overclocking Matthew Garrett
2011-07-22 14:41 ` Borislav Petkov
2011-07-22 14:49 ` Matthew Garrett
2011-07-24 3:06 ` Andy Lutomirski
2011-07-24 3:28 ` Matthew Garrett
2011-07-24 3:15 ` Andy Lutomirski
2011-07-24 3:33 ` Matthew Garrett
2011-07-24 3:42 ` Andrew Lutomirski
2011-07-24 3:49 ` Matthew Garrett
2011-07-24 9:36 ` Borislav Petkov [this message]
2011-07-18 16:37 ` [PATCH v4 4/7] ACPI: Add fixups for AMD P-state figures Matthew Garrett
2011-07-18 16:37 ` [PATCH v4 5/7] cpufreq: Add compatibility hack to powernow-k8 Matthew Garrett
2011-07-18 16:37 ` [PATCH v4 6/7] cpufreq: Remove support for hardware P-state chips from powernow-k8 Matthew Garrett
2011-07-22 14:43 ` Borislav Petkov
2011-07-18 16:37 ` [PATCH v4 7/7] cpufreq: Add boost alias to cpb Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110724093614.GA9391@aftab \
--to=bp@amd64.org \
--cc=Andreas.Herrmann3@amd.com \
--cc=cpufreq@vger.kernel.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@mit.edu \
--cc=mark.langsdorf@amd.com \
--cc=mjg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox