[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 Fri, 2015-01-16 at 16:34 +0000, Jan Beulich wrote:
> >>> On 16.01.15 at 17:16, <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2015-01-16 at 16:06 +0000, 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...
> > 
> > Unlike sysctls, physdevop-s are exposed to/stable for dom0 too aren't
> > they?
> 
> Sure, just like platformop-s. What is it I'm not understanding you
> try to point out with your question?

By moving from a sysctl to a physdev op we would then have to declare
the interface stable and lose the ability to change it in the future,
and since it didn't look like the intention here was to expose to dom0
(make more efficient didn't imply that at least) that seems a bit
unnecessary.

Ian.


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