linux-kernel - Re: acpi_idle: Very idle Core i7 machine never enters C3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 May 2010 01:43:26 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Philip Langdale <philipl@...rt.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.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, luming.yu@...el.com, venki@...gle.com
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

> >> I am hopeful that the "right thing to do" is to not look at bm-status
> >> and that perhaps there is a bug where we are looking at it
> >> "by mistake".
> > 
> > https://patchwork.kernel.org/patch/58962/ - it seems to be a win.
> 
> Indeed. This patch does solve the C6 problem. I'm not in a position to
> speak about whether there's any undesirable I/O latency, but it
> passes the basic sanity check.
> 
> I have filed https://bugzilla.kernel.org/show_bug.cgi?id=15886 with
> my acpi dump - assuming that's still useful.

Luming's patch above basically deletes acpi_idle_bm_check() --
the BM_STS check -- from the C3 path on all Intel SMP boxes.
This is effectively the same as my test patch
https://patchwork.kernel.org/patch/77370/
that made acpi_idle_bm_check() do nothing.

I'm told by the hardware guys that BM_STS is _not_ always
a NOP, and so we're not supposed to simply ignore it on C3 --
though it should be extremely rare that we see it set.
If it is ever set, it should go on and off depending on 
activity on some latency sensitive device, like out on the LPC.
It may be possible for the BIOS writer to configure the chipset
so that BM_STS is enabled always, presumably to accomodate
some latency sensitve device -- or maybe by mistake.

(is it observed to be set always on your systems, or does
 it ever change its value?)

The logic in Luming's patch doesn't make sense to me.
bm_check and bm_control are related to C3 need to flush
the cache or ability to invoke ARB_DIS.  They are not
directly related to BM_STS -- which is a bit that tells
us if there has recently been bus master activity of
a type that would break us out of C3.

-Len Brown, Intel Open Source Technology Center

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