From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RESEND 05/12] xen: numa-sched: make space for per-vcpu node-affinity Date: Tue, 5 Nov 2013 23:15:50 +0100 Message-ID: <1383689750.15457.19.camel@Abyss> References: <20131105142844.30446.78671.stgit@Solace> <20131105143500.30446.9976.stgit@Solace> <5279143702000078000FFB15@nat28.tlf.novell.com> <527908B2.5090208@eu.citrix.com> <5279189502000078000FFB7F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2219906015258538618==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vdov1-0008L3-VI for xen-devel@lists.xenproject.org; Tue, 05 Nov 2013 22:16:16 +0000 In-Reply-To: <5279189502000078000FFB7F@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: MarcusGranado , Justin Weaver , Ian Campbell , Li Yechen , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Matt Wilson , xen-devel , Daniel De Graaf , KeirFraser , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============2219906015258538618== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xtPrb9tLl1GJvpZgmXJI" --=-xtPrb9tLl1GJvpZgmXJI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2013-11-05 at 15:11 +0000, Jan Beulich wrote: > >>> On 05.11.13 at 16:03, George Dunlap wro= te: > > On 11/05/2013 02:52 PM, Jan Beulich wrote: > >>>>> On 05.11.13 at 15:35, Dario Faggioli wr= ote: > >>> @@ -197,6 +199,13 @@ struct vcpu > >>> /* Used to restore affinity across S3. */ > >>> cpumask_var_t cpu_affinity_saved; > >>> > >>> + /* > >>> + * Bitmask of CPUs on which this VCPU prefers to run. For both t= his > >>> + * and auto_node_affinity access is serialized against > >>> + * v->domain->node_affinity_lock. > >>> + */ > >>> + cpumask_var_t node_affinity; > >> > >> This all looks quite sensible, except for the naming here: We > >> already have a node_affinity field in struct domain, having a > >> meaning that one can expect with this name. So you break > >> both consistency and the rule of least surprise here. How > >> about just "preferred_cpus"? > >=20 > > Actually, would it make more sense to remove node_affinity from the=20 > > domain struct, and have the tools manually set the node_affinity for th= e=20 > > various vcpus if the user attempts to set the "domain numa affinity"? >=20 > Quite likely, yes. But that doesn't mean that the name can be kept > as is. >=20 Not really. Well, it sure is possible, but it's a bit more involved than it sounds, as the node_affinity field in struct domain drives all the actual memory allocations, and it's maintained in a nodemask_t as that's easier to use in that circumstance. Getting rid of it would mean going through the node_affinity of all vcpus and build such node mask all the times (or something like that), which I think is both more code and less performance! :-P (BTW, seeing the rest of the e-mails, I think you ended up realizing that, but still...) So, as I'll say replying to the other messages, I'm fine with changing names, much less with removing d->node_affinity. 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) --=-xtPrb9tLl1GJvpZgmXJI 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) iEYEABECAAYFAlJ5bhcACgkQk4XaBE3IOsTXmACePX2+NM3rEl4iF1cb1+WhDCxk W5UAoJBZK2Mmli6GUTAMKJODuw2hcqy2 =Tbpt -----END PGP SIGNATURE----- --=-xtPrb9tLl1GJvpZgmXJI-- --===============2219906015258538618== 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 --===============2219906015258538618==--