[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Wed, 21 Oct 2009 16:35:00 +0100
  • Cc:
  • Delivery-date: Wed, 21 Oct 2009 08:35:33 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcpSYYhLaiu6Y7GrS/+4MyhOUDb+MQAAoSaU
  • Thread-topic: [Xen-devel] why are deep cstates disabled?

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.