From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: NUMA TODO-list for xen-devel Date: Wed, 08 Aug 2012 01:53:45 +0200 Message-ID: <1344383625.1890.17.camel@Solace> References: <1343837796.4958.32.camel@Solace> <1343840334.4958.45.camel@Solace> <5019C3F7.1080404@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0548752285100658640==" Return-path: In-Reply-To: <5019C3F7.1080404@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Malte Schwarzkopf Cc: Andre Przywara , Anil Madhavapeddy , George Dunlap , Andrew Cooper , xen-devel , Jan Beulich , "Zhang, Yang Z" , Steven Smith List-Id: xen-devel@lists.xenproject.org --===============0548752285100658640== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-q7TZ3Ivb5WO6flBclQN2" --=-q7TZ3Ivb5WO6flBclQN2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-08-02 at 01:04 +0100, Malte Schwarzkopf wrote: > > Wow... That's really cool. I'll definitely take a deep look at all thes= e > > data! I'm also adding the link to the wiki, if you're fine with that... >=20 > No problem with adding a link, as this is public data :) If possible, > it'd be splendid to put a note next to this link encouraging people to > submit their own results -- doing so is very simple, and helps us extend > the database. Instructions are at > http://www.cl.cam.ac.uk/research/srg/netos/ipc-bench/ (or, for a short > link, http://fable.io). >=20 Ok, I've tried doing this, here it is how it looks: http://wiki.xen.org/wiki/Xen_NUMA_Roadmap http://wiki.xen.org/wiki/Xen_NUMA_Roadmap#Inter-VM_dependencies_and_commun= ication_issues Thanks also for the references, I'll definitely take a look at them. :-) > One interesting thing to look at (that we haven't looked at yet) is what > memory allocators do about NUMA these days; there is an AMD whitepaper > from 2009 discussing the performance benefits of a NUMA-aware version of > tcmalloc [3], but I have found it hard to reproduce their results on > modern hardware. Of course, being virtualized may complicate matters > here, since the memory allocator can no longer freely pick and choose > where to allocate from. >=20 > Scheduling, notably, is key here, since the CPU a process is scheduled > on may determine where its memory is allocated -- frequent migrations > are likely to be bad for performance due to remote memory accesses, > That might be true for Linux, but it's not so much true (fortunately :-P) for Xen. However, I also think scheduling is a very important aspect of this whole NUMA thing... I'll repost my NUMA aware credit scheduler patches soon. > although we have been unable to quantify a significant difference on > non-synthetic macrobenchmarks; that said, we did not try very hard so far= . >=20 I think both kinds of benchmarks are interesting. I tried to concentrate a bit on macrobenchmark (specjbb, I'll let you decide if that's synthetic or not :-D). Another issue, if we want to tackle the problem of communicating/cooperatin= g VMs, pops up at the interface level, i.e., how do we want the user to tell us that 2 (or more) VMs are "related"? Up to what level of detail? Should this "relationship" be permanent or might it change over time? 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) --=-q7TZ3Ivb5WO6flBclQN2 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) iEYEABECAAYFAlAhqokACgkQk4XaBE3IOsSeVQCdEBkOx3JJd5sqXfLTo8uJDtlF uXwAn07AA5nNEWVQBEpvCNix/4Vpfgz0 =JEng -----END PGP SIGNATURE----- --=-q7TZ3Ivb5WO6flBclQN2-- --===============0548752285100658640== 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 --===============0548752285100658640==--