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][PATCH] Revert Jan's patch (c/s 18879) since now itcanb

To: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel][PATCH] Revert Jan's patch (c/s 18879) since now itcanbe achieved by xenpm tool now
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 23 Dec 2008 08:38:23 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 23 Dec 2008 00:38:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <706158FABBBA044BAD4FE898A02E4BC21C7FDB4A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AclkHcfZNpERRbhfRTy+IvjSVCpxEgAg83pAAA4OwK0=
Thread-topic: [Xen-devel][PATCH] Revert Jan's patch (c/s 18879) since now itcanbe achieved by xenpm tool now
User-agent: Microsoft-Entourage/12.14.0.081024
On 23/12/2008 02:29, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:

> Some cpufreq governor may fail at init stage, i.e. performance governor cannot
> start at some platform with hardware flaw.
> In this case, if user select performance gov at cmdline, governor init will
> fail and then whole cpufreq init will fail, xen will have no cpufreq then.
> 
> Our idea is, first step cpufreq logic select a 'safe' governor as default,
> say, userspace governor. It will never fail, since it keep cpu freq just like
> it didn't work at init stage, so will not have any influence to perfromance,
> power, ..., etc.
> Second step, user can change to any other governor as he like, if fail,
> cpufreq logic can gracefully back to the 'old-safe-governor'.
> This way at least xen can ensure cpufreq logic successful, and safe change
> between different governors.

Two thoughts: Firstly, the user should be wary of such behaviour if they
have explicitly selected a governor on the command line. Secondly, if it is
appropriate to have cpufreq always on, why not hardcode a safe governor as a
fallback?

 -- Keir



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