Re: [Xen-devel] [PATCH 2] Add user PM control interface

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxx>


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