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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.