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

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

Jan Beulich wrote:
>>>> "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> 22.12.08 10:40 >>>
>> Jan Beulich wrote:
>>>>>> "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> 20.12.08 14:37 >>>
>>>> Revert Jan's patch (c/s 18879) since now it can be achieved by
>>>> xenpm tool now.
>>> 
>>> Please don't, and rather (as Keir suggested) add an option to also
>>> select the initial governor on the command line. While the xenpm
>>> tool is nice, older distro-s won't run it by default, and having to
>>> fiddle with the system startup scripts or running it manually (which
>>> wouldn't necessarily work if you don't do a full install of the Xen
>>> tool - e.g. to keep the distro's tools intact) isn't really
>>> desirable in certain cases. 
>>> 
>>> Jan
>> 
>> Jan,
>> 
>> It's good for old distro-s user to use cmdline to set parameter, but
>> I have some concern, since in fact cpufreq have 5 governors, with
>> ~20 status parameters and ~10 control parameters. If we add option
>> at grub 
>> cmdline to select initial governor, and add further options to set
>> control parameters, it may make confuse for user, especially
>> considered that 
>> some of the control parameters are governor-dependent (i.e. in c/s
>> 18879, the control para 'sample rate' and 'upthreshold' can only be
>> used for ondemand or conservative governor). User may confuse what
>> the 
> 
> Which is why they are being parsed in the ondemand governor's source
> file...
> 
>> default governor is, and what control parameters can be used at grub
>> cmdline for that governor.
> 
> Anything not applicable would be ignored. I don't think there's much
> confusion associated with this.
> 
> Jan

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.

Thanks,
Jinsong

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