Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.15 at 17:14, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 01/16/2015 11:06 AM, Jan Beulich wrote:
>>>>> On 16.01.15 at 16:56, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 01/07/2015 04:12 AM, Jan Beulich wrote:
>>>>>>> On 06.01.15 at 14:41, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> On 06/01/15 02:18, Boris Ostrovsky wrote:
>>>>>> Instead of copying data for each field in xen_sysctl_topologyinfo 
>>>>>> separately
>>>>>> put cpu/socket/node into a single structure and do a single copy for each
>>>>>> processor.
>>>>>>
>>>>>> There is also no need to copy whole op to user at the end, max_cpu_index 
>>>>>> is
>>>>>> sufficient
>>>>>>
>>>>>> Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the
>>> fact
>>>>>> that these are used for CPU topology. Subsequent patch will add support 
>>>>>> for
>>>>>> PCI topology sysctl.
>>>>>>
>>>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>>>>> If we are going to change the hypercall, then can we see about making it
>>>>> a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
>>>>> components which might want/need access to this information.  (i.e. I am
>>>>> still looking for a reasonable way to get this information from Xen in
>>>>> hwloc)
>>>> In which case leaving the sysctl alone and just adding a new non-sysctl
>>>> interface should be considered.
>>> (Sorry for late reply)
>>>
>>> Would a platform op be an option here or do you prefer a whole new
>>> hypercall?
>>  From an abstract pov a platform op would be fine, but iirc you had
>> a need for preempting, which doesn't work well for that hypercall.
>> A whole new one seems overkill too. Perhaps slightly bending what
>> physdevop-s are used for might be an option...
> 
> Since the plan is to query for both CPU and IO topologies physdevops 
> doesn't seem to be a logical place for that, does it?

That's why I said "slightly bending ..."

> What is the problem with preempting while in platform op? We already do 
> this for microcode updates.

But there we don't need to alter the arguments passed to the
hypercall, whereas you will need a way to encode where to
continue from.

Jan


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