Xen devel - Dec 2008 - [PATCH] Revert Jan''s patch (c/s 18879) since now it can be achieved by xenpm tool now

Revert Jan''s patch (c/s 18879) since now it can be achieved by 
xenpm tool now.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

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

>>> "Liu, Jinsong" <jinsong.liu@intel.com> 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


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

Jan Beulich wrote:
>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 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 default
governor is, and what control parameters can be used at grub cmdline for that
governor.

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

>>> "Liu, Jinsong" <jinsong.liu@intel.com> 22.12.08
10:40 >>>
>Jan Beulich wrote:
>>>>> "Liu, Jinsong" <jinsong.liu@intel.com>
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


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

Jan Beulich wrote:
>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 22.12.08
10:40 >>>
>> Jan Beulich wrote:
>>>>>> "Liu, Jinsong" <jinsong.liu@intel.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 23/12/2008 02:29, "Liu, Jinsong" <jinsong.liu@intel.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 23/12/2008 02:29, "Liu, Jinsong" <jinsong.liu@intel.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

On 23/12/2008 09:02, "Liu, Jinsong" <jinsong.liu@intel.com>
wrote:
> 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?
Sounds fine to me. Let''s see what Jan thinks too.

 -- Keir



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

>>> Keir Fraser <keir.fraser@eu.citrix.com> 23.12.08 10:06
>>>
>On 23/12/2008 09:02, "Liu, Jinsong" <jinsong.liu@intel.com>
wrote:
>
>> 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?
>
>Sounds fine to me. Let''s see what Jan thinks too.
I''m okay with this too, though I''m not entirely clear why the
userspace
governor would be safer/better than the performance one (in particular,
I''m unclear why the latter - supposedly not playing with frequencies at
all - has dependencies on certain tables to be loaded successfully). But
I admit that I didn''t get around to look at the recent code changes,
yet.

Jan


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