Re: [PATCH 2] Add user PM control interface

[Keir Fraser <keir.fraser@eu.citrix.com>]

The only reason for dom0 kernel not to use domctl/sysctl is that the
structures may be subject to change. So if you do, then the dom0 kernel in
that case becomes part of the 'matched set' with Xen itself and the tools.
As a distributor of 'whole system' software, you may not actually care about
this limitation (since you can track dependencies and easily cause all
packages to be upgraded)?

Adding some domctl/sysctl usage in the Linux kernel would actually be fine
by me, except that I do think it should be conditional on a Kconfig option
that makes the above additional constraint very clear to the user.

And actually, I don't think we've broken sysctl/domctl compatibility, or
changed their ABI version numbers, at all recently.

Personally I don't really care about support of the usual Linux pm tools,
since I suspect they will suffer from not taking into account whole system
activity rather than merely dom0 activity. But perhaps we have an acceptable
middle ground here?

 -- Keir

On 10/12/2008 09:08, "Jan Beulich" <jbeulich@novell.com> wrote:

> Was this coordinated with whoever maintains general power management
> tools on the Linux side? It would seem to me that adding this stuff to the
> sysctl interface is nice only from a pure Xen perspective. With the general
> rule of the kernel not supposed to use domctl and sysctl interfaces, it
> would mean that these tools have to use a completely distinct code path
> to handle the Xen case, whereas when this information was readily
> accessible to the Dom0 kernel, it could mimic the standard sysfs interface
> for the tools to use (with just the change that they need to be prepared
> to find more CPUs there than the kernel reports it is running on).
> 
> Jan
> 
>>>> "Liu, Jinsong" <jinsong.liu@intel.com> 10.12.08 09:46 >>>
> Add user PM control interface
> 
> This patch provide user PM control interface.
> Now it only implements cpufreq related interface.
> 
> User can use libxc to get cpufreq parameters:
> 1. common parameter independent on cpufreq governor
>     affected_cpus;
>     scaling_available_frequencies;
>     scaling_available_governors;
>     scaling_driver;
>     cpuinfo_cur_freq;
>     cpuinfo_max_freq;
>     cpuinfo_min_freq;
>     scaling_max_freq;
>     scaling_min_freq;
>     scaling_governor
> 2. parameters depend on specific governor:
>     userspace governor: scaling_setspeed;
>     ondemand governor:  sampling_rate_max;
>                         sampling_rate_min;
>                         sampling_rate;
>                         up_threshold;
> 
> User can also set cpufreq control parameters:
> 1. common control parameters:
>     scaling_governor;
>     scaling_max_freq;
>     scaling_min_freq;
> 2. control parameters depend on specific governor:
>     userspace governor: scaling_setspeed;
>     ondemand governor:  sampling_rate;
>                         up_threshold;
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>