This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] xen cpuidle c states

To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] xen cpuidle c states
From: Andrew Lyon <andrew.lyon@xxxxxxxxx>
Date: Thu, 5 Nov 2009 09:30:15 +0000
Delivery-date: Thu, 05 Nov 2009 01:30:37 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XB92xzBgfcg+Q0Fv4Vf78UB4YupE1o2FRvIDIclcPLU=; b=mxACd/MePv9LoOmYAQnW9q8EHso7xrAPcHZNQ+Q0KJIgfiAugV7RWquMlPQOdbEowl cFBfcq5nZm705vRftWclD2F+29bynOpfU4KhSBCLjaeN+vHKKuOLJSQzD7k0X+djp/J/ OBYNsnAZVB56D830O7dfzebJMMjhIn+ciM2zk=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LPbeFTmv3gQQCpR7On+YUydmgqKAPaiBxVqeALHLgwFG6G/Xb0vlp4A5F/Ox9DJi3I o+gVQch8puX2fFf7rkVH85nKpEv9FxQYY5yN9BBh3JeqcB6RqkWSHuwddvPREdBEYT+9 XqNgcN2dpk8SDKU1Z+J9uD9FybFFOFS4I2/Fo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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) )
        if ( !hpet_broadcast_is_available() )
            if ( xen_cpuidle == -1 )
                xen_cpuidle = 0;
                printk("CPUIDLE: disabled due to no HPET. "
                       "Force enable with 'cpuidle'.\n");
                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....


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>