From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: 4.2 Release Plan / TODO Date: Wed, 02 May 2012 17:02:45 +0200 Message-ID: <1335970965.2961.51.camel@Abyss> References: <1335272011.4347.108.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2882401088892209699==" Return-path: In-Reply-To: <1335272011.4347.108.camel@zakaz.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 Campbell Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============2882401088892209699== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-20KBDmv7Ssxa/nnVbDr6" --=-20KBDmv7Ssxa/nnVbDr6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-04-24 at 13:53 +0100, Ian Campbell wrote:=20 > Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html >=20 > The time line is as follows: >=20 > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > I'm guessing we're still here and hence I'm proposing the following. > The updated TODO list follows. Per the release plan a strong case will > now have to be made as to why new items should be added to the list, > especially as a blocker, rather than deferred to 4.3. >=20 As it is probably known and has been repeatedly stated in various threads, xm/xend has some kind of NUMA placement policy when a new guest is being created. On the opposite hand, xl/libxl does absolutely nothing, and that looks like an issue for the xl-xend feature parity we're aiming at. What xend basically does is trying to figure out where to put a guest (according to some heuristics) and it then pins its vcpus there. The NUMA series I posted also introduces some placement heuristics into xl, and I can easily take the scheduling/affinity modification apart and do pin vcpus basing on the outcome of the heuristics, just like xend. Yes, I noticed this for the first time way earlier than now, but it's only now that it came to my mind that this could be quite a serious feature parity issue, and that I can (try to!) fix with a reasonably small effort. Therefore, I'm officially proposing to add "automatic NUMA placement and vcpu pinning in xl" here below: > tools, blockers: > ...=20 > * xl compatibility with xm: > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > reported by Fabio Fantoni in > <4F9672DD.2080902@tiscali.it> > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > Dieter has posted a patch. * does not automatically try to select a (set of)=20 node(s) on which to create a VM and pin its vcpus there. The strong case I'm making is that not having this is a regression wrt default xend behaviour, and it could upset and break stuff for people expecting the toolstack tacking care about NUMA, at least in some rough way (which btw is what xend is doing). I'm not far from having the patches so, if the proposal is accepted, I can post them next week, I'm quite sure. Thoughts? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-20KBDmv7Ssxa/nnVbDr6 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+hTJUACgkQk4XaBE3IOsS/xwCeOVHWpKdbOkCcCPSZds0mzsZq fVwAoKF9dak6B9s2iK/JgEFGG8kRCZYf =FN6c -----END PGP SIGNATURE----- --=-20KBDmv7Ssxa/nnVbDr6-- --===============2882401088892209699== 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 --===============2882401088892209699==--