[Xen-devel] xen cpuidle c states

[Andrew Lyon <andrew.lyon@xxxxxxxxx>]

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