Re: [Xen-devel] Core parking feature enable

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Jan Beulich wrote:
>>>> On 01.03.12 at 12:14, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Unfortunately, yes, though cumbersome is not basic reason user space
>> approach is not preferred. Core parking is a power management staff,
>> based on dynamic physical details like cpu topologies and maps owned
>> by hypervisor. It's natural to implement 
> 
> CPU topology is available to user space, and as far as I recall your
> hypervisor patch didn't really manipulate any maps - all it did was
> pick what CPU to bring up/down, and then carry out that decision.

No. threads_per_core and cores_per_socket exposed to userspace is pointless to 
us (and, it's questionable need fixup).

Core parking depends on following physical info (no matter where it implement):
1. cpu_online_map;
2. cpu_present_map;
3. cpu_core_mask;
4. cpu_sibling_mask;
all of them are *dynamic*, especially, 3/4 are varied per cpu and per 
online/offline ops.

For userspace, consider
- userspace need keep syncing with hypervisor, after each online/offline ops 
and for each cpu;
- extending new policy need expose whatever physical info it need;
technically it maybe possible to do so, but I doubt it's really necessary.

> 
>> it at hypervisor side, like what other xen power management staffs
>> do. Based 
> 
> Other power management stuff can't be easily done in user space.

I think it's more appropriate not to separate 1 logic into 2 hierarchies.

> 
>> on same reason does native linux choose to implement it at kernel,
>> not at user space.
> 
> Sorry, no, I don't consider Linux having taken (or going to take -
> after all I can't find the word "park" when grepping 3.3-rc5's
> drivers/acpi/, so I assume the patch isn't in yet) a questionable
> decision a reason for 
> Xen to follow blindly.
> 

Kernel named it as acpi pad (Processor Aggregator Device).
Xen hypervisor didn't name it as 'pad' because it's too acpi specific, core 
parking is a more general name.

Thanks,
Jinsong

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