ACPI: make acpi_idle Nehalem-aware
in [Kernel]
|
Prev: [PATCH] x86: auditsyscall: fix fastpath return value after reschedule
Next: fix return value for mb_cache_shrink_fn when nr_to_scan > 0
From: Len Brown on 22 Jul 2010 18:10 > I'm curious as to why you see a problem with the DL380G6 as the one I have > here happily sits in C6 when idle. yay! > your turbostat util shows: > > CPU GHz TSC %c0 %c1 %c3 %c6 %pc3 %pc6 > avg 1.64 2.27 0.16 0.12 0.00 99.71 0.00 90.15 > Looking at the bug 15886, the Access Size 0x03 entries you mentioned are all > 0x01 on this system. I've also uploaded the acpidump from this DL380G6 to that > bug so that you can check I've not just looked in the wrong place. You read it correctly, your BIOS does not request BM_STS, mjg59's does. > Did the first acpidump come from a system with the 'HP Power Regulator' > setting in the bios set to OS Control mode ? My system is set this way and it > seems to work as expected. I expect that is to enable PCC, which would change P-states, but unlikely would have an effect on C-states. If you can try it both ways that might be good to know. (include powertop display once again) Of course, the default setting is what 99% of customers use... > The other settings for this option appear to be designed to override OS power > management controls, for example the description of the 'Static High > Performance' option suggests it'll somehow force the CPU to operate in the > highest performance mode all of the time: "HP Static High Performance Mode: > Processors will run in their maximum power/performance state at all times > regardless of the OS power management policy". This is BIOS writer "value add". Unclear how it migh be an improvement over what Linux has been shipping for years. > If this does turn out to be as simple as a bios setting, should we really be > trying to workaround what may be a legitimate decision by the servers admin ? Ideally we will do exactly as the BIOS requests. However, somtimes what they request makes lots of sense on some version of Windows, and may make less sense when running Linux. Please upload the output from dmidecode to the bug report. I am hopeful that you have a current BIOS and that Matthew may have an pre-production BIOS. thanks, 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Iain on 23 Jul 2010 08:50 Len Brown wrote: > You read it correctly, your BIOS does not request BM_STS, mjg59's does. Right, and on a DL360 G6 with the 07-24-2009 bios version I saw the same. > I expect that is to enable PCC, which would change P-states, > but unlikely would have an effect on C-states. I found another option in the bios to limit or disable the C-states today, so plenty of opportunity to configure the system into an odd state. > If you can try it both ways that might be good to know. > (include powertop display once again) > Of course, the default setting is what 99% of customers use... I'll upload an archive to the bugzilla entry with the details. What seems to happen is that when you set the default Balanced Power and Performance mode the CST code vanishes completely and the processor manages to get to c6 some of the time. Enable OS Control mode and the bad CST code appears. > This is BIOS writer "value add". > Unclear how it migh be an improvement over what Linux has been shipping > for years. Well yes, having Linux and the bios fighting for control probably isn't going to help. > Please upload the output from dmidecode to the bug report. > I am hopeful that you have a current BIOS and that > Matthew may have an pre-production BIOS. I've uploaded an archive with dmidecode, turbostat and powertop dumps. There are dumps with the bios set to the default, and to OS Control mode. The original bios on my DL360G6 was 07-24-2009 and has the same issue as Matthew. I upgraded the machine to the latest 2010.05.15 and repeated the tests. Good news is that the new bios has fixed the CST code so that the Access length values are all 0x01 when they're present and the dumps show the processor getting into c6 much more. So you were correct, bios fix was needed. Iain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 3 Aug 2010 03:00 On Wed 2010-07-21 17:31:27, Len Brown wrote: > From: Len Brown <len.brown(a)intel.com> > > The BIOS exports deep C-states on modern Intel processors > as "C3-type" to satisfy various legacy Operating Systems. Can you elaborate on this? I though the only difference between C2-type and C3-type is busmastering... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 3 Aug 2010 03:10
On Tue, Aug 03, 2010 at 08:55:14AM +0200, Pavel Machek wrote: > On Wed 2010-07-21 17:31:27, Len Brown wrote: > > From: Len Brown <len.brown(a)intel.com> > > > > The BIOS exports deep C-states on modern Intel processors > > as "C3-type" to satisfy various legacy Operating Systems. > > Can you elaborate on this? I though the only difference between > C2-type and C3-type is busmastering... The main difference is latency. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |