From: Andre Przywara <andre.przywara@amd.com>
To: Dulloor <dulloor@gmail.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Dan Magenheimer <dan.magenheimer@oracle.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <Keir.Fraser@eu.citrix.com>,
Papagiannis Anastasios <apapag@ics.forth.gr>
Subject: Re: Xen 3.4.1 NUMA support
Date: Tue, 10 Nov 2009 08:49:56 +0100 [thread overview]
Message-ID: <4AF91B24.7060207@amd.com> (raw)
In-Reply-To: <940bcfd20911092256t6c664d09ofced3db50211b6da@mail.gmail.com>
Dulloor wrote:
> I am not finding this. Can you please point to the code ?
tools/python/xen/xend/XendDomainInfo.py (around line 2600)
with the core code being:
-------------
index = nodeload.index( min(nodeload) )
cpumask = info['node_to_cpu'][index]
for v in range(0, self.info['VCPUs_max']):
xc.vcpu_setaffinity(self.domid, v, cpumask)
--------------
The code got introduced with c/s 17131 and later got refined with c/s
17247 and c/s 17709.
>
> numa=on/off is only for setting up numa in xen (similar to the linux
> knob, but turned off by default). The allocation of memory from a
> single node (that you observe) could be because of the way
> alloc_heap_pages is implemented (trying to allocate from all the heaps
> from a node, before trying the next one)
Yes, but if the domain is pinned before it allocated it's memory, then
the natural behavior of Xen is to take memory from this local node.
> - try looking at dump_numa
> output. And, affinities are not set anywhere based on the node from
> which allocation happens.
It is the other way round, first the domain is pinned, later the memory
is allocated (based on the node to which the currently scheduled CPU is
belonging to).
Regards,
Andre.
>
> -dulloor
>
> On Mon, Nov 9, 2009 at 5:51 PM, Andre Przywara <andre.przywara@amd.com> wrote:
>> George Dunlap wrote:
>>> Andre Przywara wrote:
>>>> BTW: Shouldn't we set finally numa=on as the default value?
>>>>
>>> Is there any data to support the idea that this helps significantly on
>>> common systems?
>> I don't have any numbers handy, but I will try if I can generate some.
>>
>> Looking from a high level perspective it is a shame that it's not the
>> default: With numa=off the Xen domain loader will allocate physical memory
>> from some node (maybe even from several nodes) and will schedule the guest
>> on some other (even rapidly changing) nodes. According to Murphy's law you
>> will end up with _all_ the memory access of a guest to be remote. But in
>> fact a NUMA architecture is really beneficial for virtualization: As there
>> are close to zero cross domain memory accesses (except for Dom0), each node
>> is more or less self contained and each guest can use the node's memory
>> controller almost exclusively.
>> But this is all spoiled as most people don't know about Xen's NUMA
>> capabilities and don't set numa=on. Using this as a default would solve
>> this.
>>
>> Regards,
>> Andre.
>>
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448 3567 12
----to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Andrew Bowd; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2009-11-10 7:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-04 12:02 Xen 3.4.1 NUMA support Papagiannis Anastasios
2009-11-04 12:32 ` Keir Fraser
2009-11-06 18:07 ` Dan Magenheimer
2009-11-09 11:33 ` George Dunlap
2009-11-09 11:39 ` Dulloor
2009-11-09 12:29 ` George Dunlap
2009-11-09 12:51 ` Dulloor
2009-11-09 11:44 ` Juergen Gross
2009-11-09 12:07 ` George Dunlap
2009-11-09 12:40 ` Keir Fraser
2009-11-09 15:02 ` Andre Przywara
2009-11-09 15:06 ` George Dunlap
2009-11-09 22:51 ` Andre Przywara
2009-11-10 6:56 ` Dulloor
2009-11-10 7:49 ` Andre Przywara [this message]
2009-11-13 14:14 ` Andre Przywara
2009-11-13 14:29 ` Ian Pratt
2009-11-13 15:25 ` George Dunlap
2009-11-13 15:35 ` Ian Pratt
2009-11-13 15:27 ` Keir Fraser
2009-11-13 15:40 ` Ian Pratt
2009-11-13 16:02 ` Keir Fraser
2009-11-13 14:31 ` Keir Fraser
2009-11-13 15:38 ` Ian Pratt
2009-11-09 15:19 ` Jan Beulich
2009-11-10 1:46 ` Ian Pratt
2009-11-10 8:51 ` Jan Beulich
2009-11-10 8:57 ` Keir Fraser
2009-11-12 16:09 ` Keir Fraser
2009-11-30 15:40 ` [PATCH] tools: avoid over-commitment if numa=on Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AF91B24.7060207@amd.com \
--to=andre.przywara@amd.com \
--cc=Keir.Fraser@eu.citrix.com \
--cc=apapag@ics.forth.gr \
--cc=dan.magenheimer@oracle.com \
--cc=dulloor@gmail.com \
--cc=george.dunlap@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.