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>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/12/2008 10:04, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> 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.Oh, another thing would be that, since this at least initially would be used only for passthrough of info to userspace, the kernel could gracefully disable this feature if not executed on a compatible Xen version. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/12/2008 10:04, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> 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.Thinking some more, this doesn''t work well unless we start guaranteeing source compatibility at least... Perhaps it''s time now to make stronger guarantees about the domctl and sysctl interfaces. Really in this case it depends: is support for Linux pm tools going to be practically useful, especially in the general cases such as #dom0-cpus !#physical-cpus? It does seem a bit dubious to me. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <keir.fraser@eu.citrix.com> 10.12.08 11:32 >>> >Really in this case it depends: is support for Linux pm tools going to be >practically useful, especially in the general cases such as #dom0-cpus !>#physical-cpus? It does seem a bit dubious to me.I''m not certain either, which is why I asked whether this was sync-ed with the maintainers of these tools. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Jan Beulich >Sent: Wednesday, December 10, 2008 6:41 PM > >>>> Keir Fraser <keir.fraser@eu.citrix.com> 10.12.08 11:32 >>> >>Really in this case it depends: is support for Linux pm tools >going to be >>practically useful, especially in the general cases such as >#dom0-cpus !>>#physical-cpus? It does seem a bit dubious to me. > >I''m not certain either, which is why I asked whether this was >sync-ed with >the maintainers of these tools. >I don''t think supporting linux pm tools an easy work, or even a sane stuff: First, dom0 doesn''t have global view to whole system. For example, PowerTOP relies on /proc/interrupts to count for break event summary. Then you need tweak that interface to include irqs owned by Xen and other domains, and update its status when it''s opened for read. More important is, I don''t think every device owned by xen/domU can find a placeholder within dom0''s namespace, considering current per-domain pirq, or in future maybe per-cpu local vector allocation. Even that''s viable, finally it''d be still preferred to have some virtualization aware concept e.g. to report a more informative result like which domains contribute how many break events instead of a raw information. Then, It''s a mess to mix cpu nodes between those available to dom0 and other nodes which are only placeholder to carry physical cpu attribute. Especially for those combining both purposes, for example, some attributes under cpu0 node is for dom0''s vcpu0 and others for physical cpu0. You have to disable existing linux stuff in case contending for same attribute, and those lines may be not a single module and then you need add condition check into those common files. Also it''s possible for user request failed to reach xen specific driver, due to some higher level check on vcpu existence. IOW, I''m inclined to think in future virtualization specific pm tool would be more useful, which acquire hypervisor pm stats directly and then can show a more informative picture to user. That said, I''d like to see current domctl/sysctl approach as the base for subsequent pm area development. Xenpm is the only user on those interface by far, which can be a good example for more advanced pm tools since we already provide equivalent control knobs as linux side. People can try to support linux pm tools by tweaking dom0 kernel, but current approach is the base anyway. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel