[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] xen cpuidle c states
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |