From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 08/14] xen: derive NUMA node affinity from hard and soft CPU affinity Date: Tue, 19 Nov 2013 17:35:17 +0100 Message-ID: <1384878917.15360.26.camel@Solace> References: <20131118175544.31002.79574.stgit@Solace> <20131118181745.31002.73423.stgit@Solace> <528B9DCC0200007800104A16@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8400695999528975314==" Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VioH8-0007Sz-Mj for xen-devel@lists.xenproject.org; Tue, 19 Nov 2013 16:35:42 +0000 In-Reply-To: <528B9DCC0200007800104A16@nat28.tlf.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: Marcus Granado , Justin Weaver , Ian Campbell , Li Yechen , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Matt Wilson , xen-devel , Keir Fraser , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============8400695999528975314== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L2Ofnr/CYhuyFoCcXhqf" --=-L2Ofnr/CYhuyFoCcXhqf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-11-19 at 16:20 +0000, Jan Beulich wrote: > >>> On 18.11.13 at 19:17, Dario Faggioli wrot= e: > > if a domain's NUMA node-affinity (which is what controls > > memory allocations) is provided by the user/toolstack, it > > just is not touched. However, if the user does not say > > anything, leaving it all to Xen, let's compute it in the > > following way: > >=20 > > 1. cpupool's cpus & hard-affinity & soft-affinity > > 2. if (1) is empty: cpupool's cpus & hard-affinity >=20 > Is this really guaranteed to always be non-empty? At least an > ASSERT() to that effect would be nice, as it's not immediately > obvious. >=20 I think it is, basing on how cpupools and hard affinity interact, even before this series (where hard affinity is v->cpu_affinity, the only per-vcpu affinity we have). For instance, when you move a domain to a new cpupool, it always reset v->cpu_affinity to "all" for all the domain's vcpus (see sched_move_domain()). Similarly, when removing cpus from a cpupools, if some v->cpu_affinity become empty, they get reset to "all" too (see cpu_disable_scheduler()). It also uses "all" as v->cpu_affinity for all the vcpus that, at domain creation time, have an affinity which has an empty intersection with the cpupool where the domain is being created. So, yes, I really think (2.) is guaranteed to be non empty, and yes, I can add an ASSERT there. > > - if ( !zalloc_cpumask_var(&cpumask) ) > > + if ( !zalloc_cpumask_var(&dom_cpumask) ) > > return; > > - if ( !alloc_cpumask_var(&online_affinity) ) > > + if ( !zalloc_cpumask_var(&dom_cpumask_soft) ) >=20 > So you use zalloc_cpumask_var() here ... >=20 > > if ( d->auto_node_affinity ) > > { > > + /* > > + * We want the narrowest possible set of pcpus (to get the nar= owest > > + * possible set of nodes). What we need is the cpumask of wher= e the > > + * domain can run (the union of the hard affinity of all its v= cpus), > > + * and the full mask of where it would prefer to run (the unio= n of > > + * the soft affinity of all its various vcpus). Let's build th= em. > > + */ > > + cpumask_clear(dom_cpumask); > > + cpumask_clear(dom_cpumask_soft); >=20 > ... and then clear the masks explicitly here? >=20 AhA, right... I probably got a bit lost while reshuffling things. :-) I'll ditch these two cpumask_clear(). Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-L2Ofnr/CYhuyFoCcXhqf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEABECAAYFAlKLk0UACgkQk4XaBE3IOsS1vACdFaOWu/2cRkgc/XtrXfUSgiGu fTwAmQHc/ArtMhEjUK2RyyBTMjPTJi7V =FEZ+ -----END PGP SIGNATURE----- --=-L2Ofnr/CYhuyFoCcXhqf-- --===============8400695999528975314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8400695999528975314==--