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


Re: [Xen-devel] why are deep cstates disabled?

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] why are deep cstates disabled?
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 21 Oct 2009 16:35:00 +0100
Delivery-date: Wed, 21 Oct 2009 08:35:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <894f1f12-cf52-48c6-a1de-6b647d77d3eb@default>
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: AcpSYYhLaiu6Y7GrS/+4MyhOUDb+MQAAoSaU
Thread-topic: [Xen-devel] why are deep cstates disabled?
User-agent: Microsoft-Entourage/
On 21/10/2009 16:16, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

>> we do know that ACPI deep sleeps are working much better than
>> that on at
>> least the small range of systems we tested on. Usually
>> deep-sleep bugs have
>> symptoms more like non-deterministic hangs after hours of uptime.
> Well I tried another box, this one a Nehalem box.
> Again, I am seeing no usage of C3 and max_cstate is set to 1.
> BUT with hpetbroadcast set, it IS using C3 extensively.
> (Unfortunately, it doesn't help me as I need to test C3
> on a machine without invariant TSC.)
> But is this a bug (that C3 only works if booted with hpetbroadcast)?

I don't think it's a bug, but maybe a poor implementation choice. Possibly
hpetbroadcast should be default, or we should fall back to PIT broadcast. Or
you could just not build the RTC driver into your dom0 kernel, or not load
the module, as it is that which is triggering disable of C3. And the driver
is probably not really being of much use. Also, on newer platforms the HPET
will continue to be used okay because the HPET will support MSI and so avoid
conflicts over the legacy RTC interrupt line. Plenty of options...

 -- Keir

Xen-devel mailing list

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