[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen cpuidle c states
I suggest add a few more printks to find out what's going on. E.g., what is the value of xen_cpuidle near the end of arch/x86/setup.c:__start_xen(). How do you know only C1 is being used: is that what xenpm tells you? There could be other reasons deeper sleeps are unavailable, such as dom0 not informing Xen about their availability (misconfigured dom0 kernel?). -- Keir On 05/11/2009 09:30, "Andrew Lyon" <andrew.lyon@xxxxxxxxx> wrote: > Hi, > > I've been looking into cpuidle c state usage on my Xeon based xen > servers and I've noticed a couple of things I don't understand: > > The xenpm documentation at http://wiki.xensource.com/xenwiki/xenpm it > states that "In xen3.4, cpuidle is enabled by default since c/s > 19421.", but just over a month later that change was reversed by c/s > 19545 with comment "x86: Disable cpuidle by default unless hpet > broadcast is available." > > So I started looking at the code to see if there would be any messages > indicating whether hpet broadcast/cpuidle was enabled or not, and in > xen/arch/x86/time.c I found the following code which I am struggling > to make sense of: > > /* > * If we do not rely on PIT CH0 then we can use HPET for one-shot timer > * emulation when entering deep C states. > * XXX dom0 may rely on RTC interrupt delivery, so only enable > * hpet_broadcast if FSB mode available or if force_hpet_broadcast. > */ > if ( xen_cpuidle && !boot_cpu_has(X86_FEATURE_ARAT) ) > { > hpet_broadcast_init(); > if ( !hpet_broadcast_is_available() ) > { > if ( xen_cpuidle == -1 ) > { > xen_cpuidle = 0; > printk("CPUIDLE: disabled due to no HPET. " > "Force enable with 'cpuidle'.\n"); > } > else > { > printk("HPET broadcast init failed, turn to PIT > broadcast.\n"); > return 0; > } > } > } > > > Neither of the messages above appear in the dmesg on my Xeon based xen > servers, and they only enter C1 state, I've tried adding cpuidle to > the xen kernel parameters but it makes no difference. > > I'm probably just not understanding the code properly but it doesn't > look like it would behave as the documentation or commit comments > suggest it should.... > > Andy > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |