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] Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm

To: Len Brown <lenb@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm
From: Vaidyanathan Srinivasan <svaidy@xxxxxxxxxxxxxxxxxx>
Date: Fri, 25 Mar 2011 23:31:57 +0530
Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, ak@xxxxxxxxxxxxxxx, suresh.b.siddha@xxxxxxxxx, venki@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, arjan@xxxxxxxxxxxxxxx, Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 25 Mar 2011 11:03:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.LFD.2.02.1103250321480.32565@x980>
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: <20110322123208.28725.30945.stgit@xxxxxxxxxxxxxxxxxxx> <20110322123336.28725.29810.stgit@xxxxxxxxxxxxxxxxxxx> <20110323121458.ec7cdaf9.sfr@xxxxxxxxxxxxxxxx> <4D89CA7D.8080108@xxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103231623450.12911@x980> <4D8B550D.5000409@xxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103250321480.32565@x980>
Reply-to: svaidy@xxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
* Len Brown <lenb@xxxxxxxxxx> [2011-03-25 03:24:24]:

> > Maybe there is some other way to handle asymmetry ??
> When somebody invents a system that needs asymmetry on purpose,
> that is the time to get fancy.  Until that day, simply print a
> FW_BUG WARNING and fall back to default_idle().

We may print a warning but not switch to default_idle().  There could
be laptops that gets an extra C-State when run on battery.  So when
the ACPI _PPC event happens for the C-State change, we need to handle
the situation such that the states are refreshed for all CPUs in one step.

Basically while we are updating the new C-State, the framework should
not detect this as asymmetric and switch to default_idle().  Please
fell free to suggest a more elegant solution to handle the runtime
C-State change event, though symmetric across all CPUs.


Xen-devel mailing list