All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: 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: Fri, 13 Nov 2009 15:14:49 +0100	[thread overview]
Message-ID: <4AFD69D9.4090204@amd.com> (raw)
In-Reply-To: <4AF82FD8.6020409@eu.citrix.com>

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 did some tests on an 8 node machine. I will retry this later on 
4-nodes and 2-nodes systems, but I assume similar numbers. I used 
multiple guests in parallel each running bw_mem of lmbench, which is 
admittedly quite NUMA sensitive. I cannot publish real numbers (yet?), 
but the results were dramatic:
with numa=on I got the same results for each guest (the same as the 
native result) when the number of guests was smaller or equal the number 
of nodes (since each guest got it's own memory controller).
If I disabled NUMA aware placement by explicitly specifying cpus="0-31" 
  in the config file or booted with numa=off, the values dropped down by 
factor 3-5 (!) (even for a few guests) with some variance due to the 
random nature of core to memory mapping.
Overcommitting the nodes (letting multiple guests use each node) lowered 
the values to about 80% for two guests and 60% for three guests per 
node, but it never got anywhere close to the numa=off values.
So these results encourage me again to opt for numa=on as the default value.
Keir, I will check if dropping the node containment in the CPU 
overcommitment case is an option, but what would be the right strategy 
in that case?
Warn the user?
Don't contain at all?
Contain to more than onde node?

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

  parent reply	other threads:[~2009-11-13 14:14 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
2009-11-13 14:14         ` Andre Przywara [this message]
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=4AFD69D9.4090204@amd.com \
    --to=andre.przywara@amd.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=apapag@ics.forth.gr \
    --cc=dan.magenheimer@oracle.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.