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]

Message-ID: <20100427084134.2874d142@fido5>
Date:	Tue, 27 Apr 2010 08:41:34 -0700
From:	Philip Langdale <philipl@...rt.org>
To:	Len Brown <lenb@...nel.org>
Cc:	Jeff Garrett <jeff@...rrett.org>, Andi Kleen <andi@...stfloor.org>,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, 27 Apr 2010 03:26:34 -0400 (EDT)
Len Brown <lenb@...nel.org> wrote:

> 
> 
> Curious failure.
> I could imagine that there is something in the design of this board
> where we want to not enter a deep C-state, and thus the board and
> Linux are doing the right thing by avoiding the C-state.
> However, ignoring the bm-status check and blindly going to that state
> I would expect to impact throughput and latency, but don't see
> how that might 'serialize' the workload or otherwise cause it
> to use some cores and not others.

Hmm - and now I can't reproduce it. I got proper parallelization across
the kernel compile. I guess some sort of runtime state was messed up,
and I obviously lost that then I rebooted. :-/
 
> It is possible that we jump into those deep states just to be
> immediately forced to jump right back out.  You'd see this in
> high usage counts under /sys/devices/system/cpu/cpu*/cpuidle
> 
> turbostat, of course, would tell you the actual residency in those
> states. Of course there is a twist...  The hardware has a feature to
> recognize thrashing and may demote an OS request for a deep state into
> an actual hardware request for a shallower state.  this is one reason
> that the output of powertop (request) and turbostat (result)
> may be different.

Without the patch, Turbostat showed C3 residency of 99% for most
hyper-threads with one or two getting ~15% C6 residency. PC3 was 75%.
Cores were at their lowest P state.

With the patch, C6 residency is 99%, PC6 is 75% and 7 hyper-threads at
lowest P state with one stubborning running at a higher level.

I have a very similarly configured machine with an asus motherboard and
it doesn't have this problem - which is another reason I'm wondering if
it's an OEM screwup.

--phil
--
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/