Re: [Xen-devel] Core parking feature enable

[Keir Fraser <keir.xen@xxxxxxxxx>]

Sorry, yes, I also had missed the ACPI interaction.

On 05/03/2012 21:27, "Haitao Shan" <maillists.shan@xxxxxxxxx> wrote:

> Thanks, Keir. We did create new hypercalls.
> But for new interface(mentioned in my previous mail), I mean the
> mechanisms for kernel to notify user-space for core parking decision.
> This does *not* exist in kernel. If we add it specifically for Xen, I
> don't think kernel people would buy-in that.
> 
> Shan Haitao
> 
> 2012/3/2 Keir Fraser <keir@xxxxxxx>:
>> On 02/03/2012 09:42, "Haitao Shan" <maillists.shan@xxxxxxxxx> wrote:
>> 
>>> I would really doubt the need to create a new interface of receiving
>>> ACPI event and sending to user land (other than existing native
>>> kernel) specifically for Xen. What's the benefit and why kernel people
>>> should buy-in that?
>>> Core parking is a platform feature, not virtualization feature.
>>> Naturally following native approach is the most efficient. Why do you
>>> want to create yet another interface for Xen to do that?
>> 
>> While I sympathise with your position rather more than Jan does, the fact is
>> that it's *you* who are suggesting yet-another-Xen-interface. Whereas doing
>> it in userspace requires only existing hypercalls I believe.
>> 
>>  -- Keir
>> 
>>> Shan Haitao
>>> 
>>> 2012/3/1 Jan Beulich <JBeulich@xxxxxxxx>:
>>>>>>> On 01.03.12 at 15:31, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>>>> 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).
>>>> 
>>>> Sure this would be insufficient. But what do you think did
>>>> XEN_SYSCTL_topologyinfo get added for?
>>>> 
>>>>> 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.
>>>> 
>>>> Afaict all of these can be reconstructed using (mostly sysctl)
>>>> hypercalls.
>>>> 
>>>> Jan
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxx
>>>> http://lists.xen.org/xen-devel
>> 
>> 



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