From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v10 9/9] libxl: vnuma topology configuration parser and doc Date: Fri, 12 Sep 2014 11:02:30 +0200 Message-ID: <1410512550.4005.243.camel@Solace.lan> References: <1409718258-3276-1-git-send-email-ufimtseva@gmail.com> <1409718258-3276-7-git-send-email-ufimtseva@gmail.com> <1410455600.4005.230.camel@Solace.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7816359120703822092==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Elena Ufimtseva Cc: Keir Fraser , Ian Campbell , Stefano Stabellini , George Dunlap , Matt Wilson , Ian Jackson , "xen-devel@lists.xen.org" , Jan Beulich , Wei Liu List-Id: xen-devel@lists.xenproject.org --===============7816359120703822092== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8D2AHK9Ec/xJtTFhqzO8" --=-8D2AHK9Ec/xJtTFhqzO8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Adding Wei] On gio, 2014-09-11 at 22:04 -0400, Elena Ufimtseva wrote: > Hello Dario >=20 Hi, > Thank you for such a thorough review. > Yeah, well, sorry it took a bit! :-/ > Majority of comments make sense to me. > Cool. :-D > Now I wanted to ask about the memory ranges :) > I am not sure at this point I should have them parsed in config file > (for the case where vNUMA node has multiple ranges) and as Ian has > mentioned I will be moving > these ranges away from libxl build info. > I guess for now It will be better to leave these ranges out of scope > of parsing code. > What do you think? >=20 If, as I'm quite sure, with 'memory ranges' you're now talking about the possibility of specifying more memory region for each node, yes, given that we're keeping that out of the libxl interface, I'd live them out of xl too. If, with 'memory ranges', you mean the possibility of specifying different memory size for each node, I think I'd keep this. In fact, bbout memory, I'm fine with how you right now deal with vnuma_mem (which I suggested to rename to "vnuma_memory" or "vnuma_maxmem"), i.e.: vnuma_memory =3D [1024, 1024, 2048, 2048] When, in future, we will introduce toolstack support for defining nodes with multiple memory regions, we can extend this syntax quite easily, to something like vnuma_memory =3D ["128,896", 256,256,512"] with the following meaning: we have two nodes; node 0 has two regions, one 128MB big, the other 896MB big. Node 1 has 3 regions, the first twos 256MB big, the third 512MB big. Just to give an example. If we want, that can be even more specific, i.e.: vnuma_memory =3D ["128@0xffffaaa,896@0xccccdddd", ...] meaning: node 0 has one region 128MB big, starting at address 0xffffaaa, and another 896MB big, starting at address 0xccccdddd (ISTR we agreed on something very similar to this for Arianna's iomem series). This is just an example, of course, the point being that the current interface is good for now, and can be easily extended, in a backward compatible way. This is my take on this, hoping I understood your question. Ian's opinion is probably the one you want, though. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-8D2AHK9Ec/xJtTFhqzO8 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 v2 iEYEABECAAYFAlQStqYACgkQk4XaBE3IOsSf8gCePT9xMouUyojMvfylNB44lBTO AwQAnAqKEnZpLneWdhbXQ1dGJJAxyUVR =F6B9 -----END PGP SIGNATURE----- --=-8D2AHK9Ec/xJtTFhqzO8-- --===============7816359120703822092== 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 --===============7816359120703822092==--