Message-id: <alpine.LFD.2.00.1005251114420.4114@localhost.localdomain>
Date:	Tue, 25 May 2010 11:33:39 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	"Yu, Luming" <luming.yu@...el.com>,
	Philip Langdale <philipl@...rt.org>,
	Jeff Garrett <jeff@...rrett.org>,
	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"venki@...gle.com" <venki@...gle.com>
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, 25 May 2010, Matthew Garrett wrote:

> On the other hand, the relevant section of spec is:
> 
> "OSPM uses the BM_STS bit to determine the power state to enter when 
> considering a transition to or from the C2/C3 power state. The BM_STS is 
> an optional bit that indicates when bus masters are active. OSPM uses 
> this bit to determine the policy between the C2 and C3 power states: a 
> lot of bus master activity demotes the CPU power state to the C2 (or C1 
> if C2 is not supported), no bus master activity promotes the CPU power 
> state to the C3 power state. OSPM keeps a running history of the BM_STS 
> bit to determine CPU power state policy."
> 
> while the description of the bit itself is:
> 
> "This is the bus master status bit. This bit is set any time a system 
> bus master requests the system bus, and can only be cleared by writing a 
> “1” to this bit position. Notice that this bit reflects bus master 
> activity, not CPU activity (this bit monitors any bus master that can 
> cause an incoherent cache for a processor in the C3 state when the bus 
> master performs a memory transaction)."
> 
> which implies that as long as you don't have any cache coherency 
> concerns, it's acceptable (if potentially suboptimal) to enter C3 even 
> if the bit is set.

As I wrote, the HW people tell me that implication is usually correct,
but there exist cases where it is incorrect.  (Of course the way
it is supposed to work is that when BM_STS is not meaningful,
it always returns zero)

The ACPI spec talks about BM_STS being set by traffic that is incoherent
with the frozen cache of C3, requiring a wake up of the processor
from C3 to snoop the traffic.  It was written 10 years before the
hardware started automatically snooping the L3 when the processor was off,
and before the hardware learned how to automatically flush the cache
to get into deep C-states.  So the description is stale, but the
underlying issue is unchanged.  There exist devices which can not
handle the wakeup latency of some deep C-states.  The BM_STS bit
is a chip-set bit that the BIOS writer can use to prevent the OS
from using the deep C-states when those devices are active.

I'm told that the cases in question are some legacy devices
hanging off the LPC bus, which should be rare.  More interesting
in isochronous traffic over some 1394 controllers -- though
I don't know if Linux runs into that.  If we do, one option
would be to ignore BM_STS, but to use pm_qos to disable the
deep c-state when needed -- a mechanism we've used for
several devices in the past.

I believe that the BIOS writer also has the option to keep
BM_STS set always.  However, that doesn't make sense to me
as it would be simpler to just disable the C-state in _CST
on that platform.

So if we see a nehalem system that has BM_STS *always* set,
even when no devices are active in the system, my guess is
that the BIOS mis-configured the chip-set and we should
ignore that bit.  If BM_STS is changing at run time, then
that is a more interesting situation, and we should endeavor
to find what device activity is changing it.

Len Brown, Intel Open Source Technology Center

Powered by blists - more mailing lists