All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Ankita Garg <ankita@in.ibm.com>, Len Brown <len.brown@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 4/4] x86: interleave emulated nodes over physical nodes
Date: Fri, 9 Oct 2009 02:34:17 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.1.00.0910090233460.2838@chino.kir.corp.google.com> (raw)
In-Reply-To: <20091001085628.GD15345@elte.hu>

On Thu, 1 Oct 2009, Ingo Molnar wrote:

> > This patch interleaves emulated nodes over the system's physical 
> > nodes. This is required for interleave optimizations since 
> > mempolicies, for example, operate by iterating over a nodemask and act 
> > without knowledge of node distances.  It can also be used for testing 
> > memory latencies and NUMA bugs in the kernel.
> > 
> > There're a couple of ways to do this:
> > 
> >  - divide the number of emulated nodes by the number of physical nodes
> >    and allocate the result on each physical node, or
> > 
> >  - allocate each successive emulated node on a different physical node
> >    until all memory is exhausted.
> > 
> > The disadvantage of the first option is, depending on the asymmetry in 
> > node capacities of each physical node, emulated nodes may 
> > substantially differ in size on a particular physical node compared to 
> > another.
> > 
> > The disadvantage of the second option is, also depending on the 
> > asymmetry in node capacities of each physical node, there may be more 
> > emulated nodes allocated on a single physical node as another.
> > 
> > This patch implements the second option; we sacrifice the possibility 
> > that we may have slightly more emulated nodes on a particular physical 
> > node compared to another in lieu of node size asymmetry.
> > 
> >  [ Note that "node capacity" of a physical node is not only a function of
> >    its addressable range, but also is affected by subtracting out the
> >    amount of reserved memory over that range.  NUMA emulation only deals
> >    with available, non-reserved memory quantities. ]
> > 
> > We ensure there is at least a minimal amount of available memory
> > allocated to each node.  We also make sure that at least this amount of
> > available memory is available in ZONE_DMA32 for any node that includes
> > both ZONE_DMA32 and ZONE_NORMAL.
> > 
> > This patch also cleans the emulation code up by no longer passing the
> > statically allocated struct bootnode array among the various functions.
> > This init.data array is not allocated on the stack since it may be very
> > large and thus it may be accessed at file scope.
> > 
> > The WARN_ON() for nodes_cover_memory() when faking proximity domains is
> > removed since it relies on successive nodes always having greater start
> > addresses than previous nodes; with interleaving this is no longer always
> > true.
> > 
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
> > Cc: Ankita Garg <ankita@in.ibm.com>
> > Signed-off-by: David Rientjes <rientjes@google.com>
> > ---
> >  arch/x86/mm/numa_64.c |  211 ++++++++++++++++++++++++++++++++++++++++++------
> >  arch/x86/mm/srat_64.c |    1 -
> >  2 files changed, 184 insertions(+), 28 deletions(-)
> 
> Looks very nice. Peter, Thomas, any objections against queueing this up 
> in the x86 tree for more testing?
> 

Thanks!  Do you know when this will be merged?

  reply	other threads:[~2009-10-09  9:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-25 22:19 [patch 1/4] x86: cleanup and add missing log levels for k8 David Rientjes
2009-09-25 22:20 ` [patch 2/4] x86: export k8 physical topology David Rientjes
2009-10-12 21:31   ` [tip:x86/mm] x86: Export " tip-bot for David Rientjes
2009-09-25 22:20 ` [patch 3/4] x86: export srat " David Rientjes
2009-10-12 21:32   ` [tip:x86/mm] x86: Export " tip-bot for David Rientjes
2009-09-25 22:20 ` [patch 4/4] x86: interleave emulated nodes over physical nodes David Rientjes
2009-10-01  8:56   ` Ingo Molnar
2009-10-09  9:34     ` David Rientjes [this message]
2009-10-12 21:32   ` [tip:x86/mm] x86: Interleave " tip-bot for David Rientjes
2009-10-12 21:31 ` [tip:x86/mm] x86: Clean up and add missing log levels for k8 tip-bot for David Rientjes

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=alpine.DEB.1.00.0910090233460.2838@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=ankita@in.ibm.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /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.