[lkml]   [2008]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 0/6] AMD C1E aware idle support
On Wed, Jun 18, 2008 at 06:47:49PM -0400, Len Brown wrote:
> On Thu, 12 Jun 2008, Thomas Gleixner wrote:
> > AMD CPUs with C1E support are currently excluded from high resolution
> > timers and NOHZ support. The reason is that C1E is a BIOS controlled
> > C3 power state which switches off TSC and the local APIC timer. The
> > ACPI C-State control manages the TSC/local APIC timer wreckage, but
> > this does not include the C1 based ("halt" instruction) C1E mode. The
> > BIOS/SMM controlled C1E state works on most systems even without
> > enabling ACPI C-State control.
> What a mess.
> What is the measured power savings that justifies this effort?

IMHO the power savings are not that important when such a kernel runs
on bare metal:

(In the following C1E denotes "AMD-C1E" of course ;-)

- From what I've seen in some basic tests, power usage was not that
different between C1E+NOHZ and C1E+250Hz. (I've done tests on a
Turion X2 (RevF) Laptop, a desktop with Phenom (RevB3), and some
Turion X2 Ultra (family 0x11) prototype.)

- Just the desktop showed 2-4 Watt larger power usage with C1E+250Hz
in comparison to C1E+NOHZ.

- The Turion X2 (Ultra) systems showed almost no differences. Just
when running with C1E+1000Hz the ACPI power usage estimate reported
by powertop was slightly increased (by <1 Watt). (No differences
shown on external power meter and removed battery.)

In conclusion, I think the big benefit from that code is not improved
power savings for laptop users but that it allows highres timers and
dynticks for CPUs with C1E.

E.g. this helps a lot with virtualization -- where dynticks is
preferred for the host system.
And if you have lots of guests the number of timer interrupts can
significantly be reduced for the entire system when all guests and the
host use dynticks.

Some further (random) observations/notes from my tests:

- Using C1E (NOHZ or with periodic timer) was usually better than
running w/o C1E on those machines. (Ok, I didn't expect anything

- It did not matter which timer interrupt source was used (PIT or
HPET) in NOHZ/one-shot mode.

+ One-shot programming of HPET in comparison to PIT was faster (on
average) by a factor of 2.7 with the chipsets that I've used.

+ Of course using PIT in NOHZ mode resulted in sligtly more
interrupts as the 16-bit counter overflows at least every 0.055
seconds - and Linux even uses a maximum delta of about 27ms.

But overall no measurable difference in power usage was seen.

- "wakeups from idle" as reported by powertop are somehow inaccurate
(from my point of view). They are calculated as "number of
interrupts"/"number of online CPUs". Thus powertop shows about 125
wakeups with 250 HZ on any dual core system or about 250 wakeups
with 1000Hz on a quad-core system. But I had no time to look
further into this.

- Doing battery tests where you fully charge the battery and then
deeply discharge it are harmful, it will/might decrease full
capacity of your lithium battery and most probably decrease its
lifetime. ;-(

> While I'm okay with platform specific idle states,
> I'm not okay with the use of therm C1E here.

Valid point.
I try to address this with some patch.



 \ /
  Last update: 2008-07-04 16:39    [W:0.101 / U:0.120 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site