[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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...

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.