On Tue, 27 Apr 2010 03:26:34 -0400 (EDT) Len Brown <lenb@xxxxxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
