From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: NUMA TODO-list for xen-devel Date: Wed, 01 Aug 2012 18:47:14 +0200 Message-ID: <1343839634.4958.39.camel@Solace> References: <1343837796.4958.32.camel@Solace> <501959BE.60801@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8435584703076205533==" Return-path: In-Reply-To: <501959BE.60801@citrix.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: Andrew Cooper Cc: Andre Przywara , Anil Madhavapeddy , George Dunlap , xen-devel , Jan Beulich , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org --===============8435584703076205533== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hxuxtGRndUgIcnhdldcP" --=-hxuxtGRndUgIcnhdldcP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-08-01 at 17:30 +0100, Andrew Cooper wrote: > On 01/08/12 17:16, Dario Faggioli wrote: > > ... > > > - Automatic placement at guest creation time. Basics are there and > > will be shipping with 4.2. However, a lot of other things are > > missing and/or can be improved, for instance: > > [D] * automated verification and testing of the placement; > > * benchmarks and improvements of the placement heuristic; > > [D] * choosing/building up some measure of node load (more accurate > > than just counting vcpus) onto which to rely during placement; > > * consider IONUMA during placement; > > * automatic placement of Dom0, if possible (my current series is > > only affecting DomU) > > * having internal xen data structure honour the placement (e.g.,=20 > > I've been told that right now vcpu stacks are always allocated > > on node 0... Andrew?). > > >=20 > - Xen NUMA internals. Placing items such as the per-cpu stacks and > data area on the local NUMA node, rather than unconditionally on node > 0 at the moment. As part of this, there will be changes to > alloc_{dom,xen}heap_page() to allow specification of which node(s) to > allocate memory from. As you see, I already tried to consider that (as you told me it does that couple of weeks ago :-) ). I'll add your wording of it (much better than mine) to the wiki... I understand you're working on this, aren't you? Can I put that down to? 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) --=-hxuxtGRndUgIcnhdldcP 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) iEYEABECAAYFAlAZXZMACgkQk4XaBE3IOsTNSwCgrGgKU8jQt8a2kbhcsLYMbqib kEsAoKgFvRSZFTTICahBuzYjV8Z+SARl =Lbo6 -----END PGP SIGNATURE----- --=-hxuxtGRndUgIcnhdldcP-- --===============8435584703076205533== 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 --===============8435584703076205533==--