Re: [Xen-devel] Core parking feature enable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.02.12 at 18:48, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> Jan Beulich wrote:
>>>>> On 17.02.12 at 09:54, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>> Core parking is a power control feature and it can co-work with NPTM
>>> to control system power budget through online/offline some CPUs in
>>> the system. These patches implement core parking feature for xen.
>>> They consist of 2 
>>> parts: dom0 patches and xen hypervisor patches.
>>> 
>>> At dom0 side, patches include
>>> [Patch 1/3] intercept native pad (Processor Aggregator Device) logic,
>>> providing a native interface for natvie platform and a paravirt
>>> template for paravirt platform, so that os can implicitly hook to
>>> proper ops accordingly; [Patch 2/3] redirect paravirt template to
>>> Xen pv ops; [Patch 3/3] implement Xen pad logic, and when getting
>>> pad device 
>>> notification, it hypercalls to Xen hypervisor for core parking. Due
>>> to the characteristic of xen continue_hypercall_on_cpu, dom0
>>> seperately send/get 
>>> core parking request/result;
>>> 
>>> At Xen hypervisor side, patches include
>>> [Patch 1/2] implement hypercall through which dom0 send core parking
>>> request, and get core parking result;
>>> [Patch 2/2] implement Xen core parking. Different core parking
>>> sequence has different power/performance result, due to cpu
>>> socket/core/thread topology. This patch provide power-first and
>>> performance-first policies, users can choose core parking policy on
>>> their own demand, considering power and performance tradeoff.
>> 
>> Does this really need to be implemented in the hypervisor? All this
>> boils down to is a wrapper around cpu_down() and cpu_up(), which
>> have hypercall interfaces already. So I'd rather see this as being
>> an extension to Dom0's pCPU management patches (which aren't
>> upstream afaict)...
>> 
>> Jan
> 
> It's a design choice. Core parking is not only a wrapper around cpu_down/up, 
> it also involves policy algorithms which depend on physical cpu topology and 
> cpu_online/present_map, etc. Implement core parking at dom0 side need expose 
> all those information to dom0, with potential issues (like coherence), while 
> dom0 still need do same work as hypervisor.
> Our idea is to keep dom0 as ACPI parser, then hypercall and do rest things 
> at hypervisor side.

Actually, after some more thought, I don't even think this ought to
be implemented in the Dom0 kernel, but in user space altogether.
Afaict all information necessary is already being exposed.

Jan


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