RE: [Xen-devel][PATCH] Revert Jan's patch (c/s 18879) since now itcanbe achieved by xenpm tool now

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Keir Fraser wrote:
> 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

It's fine to me to keep cmdline parse to select cpufreq governor.
I will update my patch, final result is:
1. keep Jan's patch (c/s 18879);
2. add governor setting at cmdline;
3. set xen as default cpufreq;
4. set userspace as default governor;
5. if user set governor at cmdline --> if gov startup success, then cpufreq run 
it; if gov startup fail, then cpufreq back to default safe governor;
Is it OK?

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