From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC v2 5/7] libxl/vNUMA: VM config parsing functions Date: Mon, 14 Oct 2013 15:15:24 +0200 Message-ID: <1381756524.15420.23.camel@Abyss> References: <1379062224-13894-1-git-send-email-ufimtseva@gmail.com> <1381394293.4389.81.camel@Abyss> <1381440720.4389.90.camel@Abyss> <21079.56960.505407.925318@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6574212984719769348==" Return-path: In-Reply-To: <21079.56960.505407.925318@mariner.uk.xensource.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: Ian Jackson Cc: Ian Campbell , Li Yechen , George Dunlap , Stefano Stabellini , "xen-devel@lists.xen.org" , Elena Ufimtseva , sw@linux.com List-Id: xen-devel@lists.xenproject.org --===============6574212984719769348== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-j/67QBepAYeqhygwDv/F" --=-j/67QBepAYeqhygwDv/F Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2013-10-11 at 12:18 +0100, Ian Jackson wrote: > Dario Faggioli writes ("Re: [Xen-devel] [PATCH RFC v2 5/7] libxl/vNUMA: V= M config parsing functions"): > > On gio, 2013-10-10 at 12:25 -0400, Elena Ufimtseva wrote: > > > 3) if vdistance number of elements =3D vnodes * vnodes, take as it is= . > >=20 > > Sure. >=20 > I have some qualms about this: >=20 > Aren't there some constraints that need to be imposed ? For example, > distance[X,Y]=3D=3Ddistance[Y,X] ? What about the triangle inequality > (distance[A,B] + distance[B,C] >=3D distance[A,C]) ? >=20 I think Linux does some sanity checking of the distance table (and I think it disables NUMA if finding out something weird, Elena?). However, this (what Linux expects/checks for) shouldn't really be the only criterion, since although Linux is the only current implementation, there is no reason why this can't be implemented by other OSes. My point being that we can for sure identify some obviously pathological cases (after having reached an agreement on what that would mean), and either exit or print a warning if they show up, but I don't think it's libxl's job to fully ensure consistency. > Do we really want/need to allow the specification of any arbitrary > distance matrix (subject perhaps to such constraints) ? >=20 Personally, yes, I think we should try to stick with what the user asks us to do. Again, we perhaps can have some checking in place (this is not an hot path) and print warnings. We can also consider a symmetric matrix as a sane default and hence allow the user to specify only half of the distances. > If we do need this I think the nested lists are probably a better > syntax for specifying the whole array. =20 > Agreed. I actually wanted to say the same. Would something like this be ok? distances =3D [ [10, 20], [20, 10] ] Or this: distances =3D [ [10, 20, 30, 40], [20, 10, 20, 30], [30, 20, 10, 20], [40, 30, 20, 10] ] Which, considering the above, could also be specified as this: distances =3D [ [10, 20, 30, 40], [10, 20, 30], [10, 20], [10] ] (I.e., "distances =3D [ [10, 20, 30, 40], [10, 20, 30], [10, 20], [10] ]) Elena, what do you think? > That would also more easily > allow the user to specify only half of the symmetric matrix, and make > it syntactically clearer what's intended. >=20 Wow, I seem we're on the same pitch here. :-D 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) --=-j/67QBepAYeqhygwDv/F 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) iEYEABECAAYFAlJb7mwACgkQk4XaBE3IOsQsvQCeOejG9Jtb/GRGDV9Gd/naV0BR mSIAn0ryjkZmNFGpCbmaLdptoyriojgT =TFC3 -----END PGP SIGNATURE----- --=-j/67QBepAYeqhygwDv/F-- --===============6574212984719769348== 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 --===============6574212984719769348==--