Re: [PATCH] ACPI: make acpi_idle Nehalem-aware

From: Iain
Date: Thu Jul 22 2010 - 17:25:16 EST


Len Brown wrote:
However, we'll still have issues with systems
like the HP DL360 G6 which explicity set the
flag to ask for BM_STS checking and configure
the chipset such that BM_STS is active.
That may require a BIOS fix, or we may
have to run intel_idle on that box --
since intel_idle ignores BM_STS always
and instead relies on drivers to use pm_qos
to register device latency constraints.

I'm curious as to why you see a problem with the DL380G6 as the one I have here happily sits in C6 when idle.

your turbostat util shows:

CPU GHz TSC %c0 %c1 %c3 %c6 %pc3 %pc6
avg 1.64 2.27 0.16 0.12 0.00 99.71 0.00 90.15

and powertop has results like:

Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0,1%) Turbo Mode 0,0%
polling 0,0ms ( 0,0%) 2,27 Ghz 0,0%
C1 mwait 0,1ms ( 0,0%) 2,13 Ghz 0,0%
C2 mwait 1,0ms ( 0,0%) 2,00 Ghz 0,0%
C3 mwait 90,4ms (99,9%) 1,60 Ghz 100,0%

this is with v2.6.35-rc5-176-gcd5b8f8 and using acpi_idle. I've deliberately disabled intel_idle to test, however using intel_idle gives almost identical results.

Looking at the bug 15886, the Access Size 0x03 entries you mentioned are all 0x01 on this system. I've also uploaded the acpidump from this DL380G6 to that bug so that you can check I've not just looked in the wrong place.

Did the first acpidump come from a system with the 'HP Power Regulator' setting in the bios set to OS Control mode ? My system is set this way and it seems to work as expected.
The other settings for this option appear to be designed to override OS power management controls, for example the description of the 'Static High Performance' option suggests it'll somehow force the CPU to operate in the highest performance mode all of the time: "HP Static High Performance Mode: Processors will run in their maximum power/performance state at all times regardless of the OS power management policy".

If this does turn out to be as simple as a bios setting, should we really be trying to workaround what may be a legitimate decision by the servers admin ?

Iain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/