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:38, <Ian.Campbell@xxxxxxxxxx> wrote:
> 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.

The conversion from sysctl was something Andrew had asked for.
After some consideration I had actually indicated I'm not really
convinced of the motivation he gave, but I don't think I heard
back on this. So _if_ we want to expose this to other than the
tool stack, then _of course_ the interface can't be changed at
our liking anymore (this stability was part of what Andrew wanted
iirc).

Jan


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