From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient Date: Fri, 16 Jan 2015 16:57:53 +0000 Message-ID: <54B94311.5080209@citrix.com> References: <1420510737-22813-1-git-send-email-boris.ostrovsky@oracle.com> <1420510737-22813-3-git-send-email-boris.ostrovsky@oracle.com> <54ABE613.2090608@citrix.com> <54AD06960200007800052294@mail.emea.novell.com> <54B9349A.1050800@oracle.com> <54B945200200007800055ECD@mail.emea.novell.com> <1421425004.19839.81.camel@citrix.com> <54B94BB10200007800055F7A@mail.emea.novell.com> <1421426309.19839.84.camel@citrix.com> <54B94E250200007800055FB2@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B94E250200007800055FB2@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, ufimtseva@gmail.com, keir@xen.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 16/01/15 16:45, Jan Beulich wrote: >>>> On 16.01.15 at 17:38, wrote: >> On Fri, 2015-01-16 at 16:34 +0000, Jan Beulich wrote: >>>>>> On 16.01.15 at 17:16, wrote: >>>> On Fri, 2015-01-16 at 16:06 +0000, Jan Beulich wrote: >>>>>>>> On 16.01.15 at 16:56, wrote: >>>>>> On 01/07/2015 04:12 AM, Jan Beulich wrote: >>>>>>>>>> On 06.01.15 at 14:41, 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 >>>>>>>> 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). The real question is whether this information is useful to anything other than toolstack-like entities. I have been partially dissuaded from my stance of "yes" on this point. While it is possible that there are toolstack-like entities which want this information, there is almost nothing useful which could be done without other toolstack gubbins in place. ~Andrew