WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xen cpuidle c states

To: Andrew Lyon <andrew.lyon@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xen cpuidle c states
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 05 Nov 2009 09:51:27 +0000
Cc:
Delivery-date: Thu, 05 Nov 2009 01:51:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C7184F86.1942C%keir.fraser@xxxxxxxxxxxxx>
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
Thread-index: Acpd+xXCdOwE6aFHTzqnWh3A/6CjDQAAc2JCAAAp3wM=
Thread-topic: [Xen-devel] xen cpuidle c states
User-agent: Microsoft-Entourage/12.20.0.090605
Oh, another possibility is that deep sleeps get nobbled during dom0 boot, if
dom0 wants to use the RTC interrupt line. For some boring technical reason,
this can conflict with hpet broadcast mode and then deep sleeps get
disabled, rather than falling back to a more sensible mode of operation.

You might try addign hpetbroadcast as a Xen boot parameter to see if that
improves matters for you.

 -- Keir

On 05/11/2009 09:46, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> 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

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