From: Len Brown <lenb@kernel.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Shaohua Li <shaohua.li@intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"andi@firstfloor.org" <andi@firstfloor.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH]new ACPI processor driver to force CPUs idle
Date: Fri, 10 Jul 2009 16:29:25 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.00.0907101548200.9103@localhost.localdomain> (raw)
In-Reply-To: <20090626194908.GA11492@srcf.ucam.org>
> > Low Frequency Mode (LFM), aka Pn - the deepest P-state,
> > is the lowest energy/instruction because it is this highest
> > frequency available at the lowest voltage that can still
> > retire instructions.
> >
> > That is why it is the first method used -- it returns the
> > highest power_savings/performance_impact.
>
> For a straightforward workload on a dual package system, do you get more
> performance from two packages running at their lowest P state or from
> one package at its highest P state and a forced-idle package?
>
> Which consumes more power?
For simplicity, lets say...
Pn = P1/2 eg. P1=3GHz, and Pn=1.5 GHz.
Lets assume that the application
has zero cache and memory footprint
and performance = CPU cycles.
In that case, we could choose to either cut the
frequency of 8 threads in half, or cut the frequency
of 4 threads to 0 -- and we have a "cycle count"
performance wash.
Reality is that applications do care about memory,
and so doubling the available cache is a performance
win for P-states. If the application is something that
notices latency of multiple threads sharing a CPU
vs a thread/CPU, then P-states would again win
because of more available cores.
Current Intel multi-package systems don't quite get
down to P1/2 -- so the deepest P-state would actually
not have quite as much performance impact.
Last AMD system I saw got down to 1GHz, so on that
system P-state could (potentially) have a performance
impact greater than off-lining.
Power is more complicated.
We discussed not saving much when an HT sibling is taken
off line, right? The converse is also true, HT siblings
are almost free in terms of power. So even though an HT
sibling doesn't have the performance of a dedicated core,
it is actually one of the best performance/watt parts
of the system on many workloads. So you want to disable
this last, not first; by exhausting p-states before
you take your siblings off line.
Lets discuss turbo-mode.
Think of turbo in these terms...
The ideal system to the HW designers is one that can
spend a fixed power+electrical budget in any way
on performance.
ie. when some cores are idle, spend that budget
to make the other cores go faster -- faster even
than the advertised P0 frequency.
As turbo has the highest voltage, it has the lowest
efficiency in terms of instruction/energy.
Thus it is very important that in power limited secarios
that turbo (aka P0) be disabled first.
There is a cross-over where a C-state that is highly
optimized will be less impact on total system efficiency
than a reduced P-state. However, we don't see that
cross over on current Intel systems on workloads measured.
The reason is that they set Pn to the minimum voltage
where P-states are useful and run as fast as they
can at that voltage. If the system were throttled
say via T-states, down to an extremely low clock rate,
then C-states would win sooner.
-Len Brown, Intel Open Source Technolgy Center
next prev parent reply other threads:[~2009-07-10 20:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 4:13 [PATCH]new ACPI processor driver to force CPUs idle Shaohua Li
2009-06-24 6:39 ` Peter Zijlstra
2009-06-24 7:47 ` Shaohua Li
2009-06-24 8:03 ` Peter Zijlstra
2009-06-24 8:21 ` Shaohua Li
2009-06-26 18:16 ` Vaidyanathan Srinivasan
2009-06-29 2:54 ` Shaohua Li
2009-07-06 18:03 ` Vaidyanathan Srinivasan
2009-07-06 23:43 ` Andi Kleen
2009-07-07 0:50 ` Pallipadi, Venkatesh
2009-07-10 19:31 ` Len Brown
2009-06-24 17:20 ` Len Brown
2009-06-26 7:46 ` Peter Zijlstra
2009-06-26 16:46 ` Len Brown
2009-06-26 18:42 ` Vaidyanathan Srinivasan
2009-07-10 19:47 ` Len Brown
2009-06-26 19:49 ` Matthew Garrett
2009-07-10 20:29 ` Len Brown [this message]
2009-06-30 8:02 ` Shaohua Li
2009-07-07 8:26 ` Peter Zijlstra
2009-07-07 8:24 ` Peter Zijlstra
2009-07-10 20:41 ` Len Brown
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=alpine.LFD.2.00.0907101548200.9103@localhost.localdomain \
--to=lenb@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mjg59@srcf.ucam.org \
--cc=shaohua.li@intel.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.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