Re: NUMA TODO-list for xen-devel

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1.1: Type: text/plain, Size: 2697 bytes --]

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 these
> > data! I'm also adding the link to the wiki, if you're fine with that...
> 
> 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).
> 
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_communication_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.
> 
> 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.
> 
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/cooperating
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

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel