[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2] Add user PM control interface
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@xxxxxxxxxx> 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@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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |