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 11:34:25 -0500 Message-ID: <54B93D91.2080803@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> <54B938F3.2060900@oracle.com> <54B948750200007800055F15@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B948750200007800055F15@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 Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, Andrew Cooper , 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:20 AM, Jan Beulich wrote: >>>> On 16.01.15 at 17:14, wrote: >> On 01/16/2015 11:06 AM, 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... >> Since the plan is to query for both CPU and IO topologies physdevops >> doesn't seem to be a logical place for that, does it? > That's why I said "slightly bending ..." > >> What is the problem with preempting while in platform op? We already do >> this for microcode updates. > But there we don't need to alter the arguments passed to the > hypercall, whereas you will need a way to encode where to > continue from. I needed to do this with last version and ended up having a field in the interface structure that hypervisor updates before issuing a continuation. And I think I'd have to do the same for either platform op or physop since neither has an extra argument for passing via a continuation. -boris