From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient Date: Fri, 16 Jan 2015 12:07:29 -0500 Message-ID: <54B94551.7080303@oracle.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> <54B94311.5080209@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B94311.5080209@citrix.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: Andrew Cooper , 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 List-Id: xen-devel@lists.xenproject.org On 01/16/2015 11:57 AM, Andrew Cooper wrote: > 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. So then you are OK with keeping this in sysctl? (I actually must have misunderstood Jan's position on that from earlier discussion --- I thought he was advocating for moving away from sysctl as well). Also, a side question --- how is platform ops interface considered stable if it is versioned? I may have a different understanding of what "stable" means. -boris