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: RE: RE: RE: [Xen-devel] No C-States any longer...

To: Carsten Schiers <carsten@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 22 Jun 2011 20:31:38 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Wed, 22 Jun 2011 05:35:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <31311199.221308742578360.JavaMail.root@uhura>
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>
References: <31311199.221308742578360.JavaMail.root@uhura>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acww0LDAD6zSSyFFQfa/vdG8RbbqsQAB0tNg
Thread-topic: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> Sent: Wednesday, June 22, 2011 7:36 PM
> 
> >> There is a comment in acpi_processor_get_power_info_default it is
> >> said that all processors need to support C1 at least. So (hypothesis),
> >> if my BIOS is not implemented as specified (neither _CST nor PBLK),
> >>> shouldn't acpi_processor_get_power_info_default also bee called on my
> >> machine? Is the code exiting too early?
> >
> >You can argue that point. It exits at current point because typical BIOS
> >provide either CST or valid FADT/PBLK info. Of course even when ACPI
> >table is broken we can still make a valid C1 entry. But also note that even
> >then such ACPI Cstate information is not gathered, the kernel always
> >invokes hlt when system is idle which achieves the effect. :-)
> 
> After having had some discussion with Gigabyte, I am now sure that the BIOS
> intentionally doesn't implement C-States at all. Gigabyte says, they
> iomplemeted
> Cool'n'Quiet "instead".

great that this is clarified from the vendor. :-)

> 
> In don't share this point, as I think Spec does require either _CST or PBLK.
> Nevertheless, I think to remember that
> 
>   - xenpm did only mention C0 and C1 in the past
>   - but xenpm did so and does not any longer

there're always various ACPI-incompatible boxes in the market, and the reason 
for
the different behavior may come from the fact that newer kernel more conforms
to the ACPI spec now.

> 
> Eventually, even if it's only cosmetic, something needs to be changed in order
> to reflect that case by setting up C1 in such a case. I am sorry, but I was 
> not
> able to do it.

I agree that from statistics p.o.v, C1/C0 should be always exposed regardless of
whether ACPI is broken.

Thanks
Kevin


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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