lkml.org 
[lkml]   [2010]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: acpi_idle: Very idle Core i7 machine never enters C3
On Tue, 27 Apr 2010 03:26:34 -0400 (EDT)
Len Brown <lenb@kernel.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


\
 
 \ /
  Last update: 2010-04-27 17:45    [W:0.409 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site