public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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