From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 11 of 11] Some automatic NUMA placement documentation Date: Fri, 08 Jun 2012 17:19:06 +0200 Message-ID: <1339168746.5003.20.camel@Solace> References: <20423.35189.904831.64711@mariner.uk.xensource.com> <1338478895.15014.60.camel@Solace> <20434.1446.507811.744249@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0434216109526874126==" Return-path: In-Reply-To: <20434.1446.507811.744249@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: Andre Przywara , Ian Campbell , Stefano Stabellini , George Dunlap , Juergen Gross , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============0434216109526874126== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-urQqpiHinmrJfTw2X2Vr" --=-urQqpiHinmrJfTw2X2Vr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-06-08 at 15:01 +0100, Ian Jackson wrote: > > Right, that is of couse an option, and I thought about going that way > > for quite a while. However, what I think is best for libxl is to provid= e > > a set of building blocks for its user to be able to implement the actua= l > > heuristics. >=20 > The difficulty with this is that this is supposedly becoming a stable > API. If we change the approach later, we may want to change the API. > Do we know clearly enough what building blocks are needed and what > they should be like ? >=20 No, you all are right, not yet... More investigation is needed here and it is not now the moment to do it. > > Doing it the other way, i.e., one big function doing everything, would > > mean that as soon as we want to change or improve the placement > > heuristics, we need to modify the behaviour of that API call, which I > > think it is suboptimal. >=20 > If we have a function whose documented behaviour is `try to do a > roughly optimal thing' then improving its optimisation is not a change > to the API semantics. >=20 > Specifically, existing code then will, when upgraded to a newer libxl, > behaviour differently - better, we hope. Is that not the intent ? >=20 It is. I'm changing this all into something like "when you do not say anything, libxl will place the domain `sensibly`, +/- as xend was doing". We'll then add all the necessary interface and API in place during 4.3. > > So, like it is right now, the actual heuristics is implemented in xl, o= n > > top of these placement candidate generation and manipulation facilities= , > > which I finally decided it was the way I liked this whole thing > > most. :-) >=20 > So how much of the code currently in libxl should be reproduced in > (say) libvirt ? >=20 Again, I agree. Let's leave this for now, but I'll definitely investigate this later. Thanks a lot for looking into this, :-) Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-urQqpiHinmrJfTw2X2Vr 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.12 (GNU/Linux) iEYEABECAAYFAk/SF+oACgkQk4XaBE3IOsRmmACfbhgNqVU1jo7/rqmfKUwqAdz3 OfoAnjDFKkinwGSgjXAplcKTXfQQRnX4 =m1O0 -----END PGP SIGNATURE----- --=-urQqpiHinmrJfTw2X2Vr-- --===============0434216109526874126== 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 --===============0434216109526874126==--