All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Avoid allocating during interleave from almost full nodes
Date: Mon, 6 Nov 2006 13:20:29 -0800	[thread overview]
Message-ID: <20061106132029.28cd88b5.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0611061252140.29760@schroedinger.engr.sgi.com>

On Mon, 6 Nov 2006 12:58:52 -0800 (PST)
Christoph Lameter <clameter@sgi.com> wrote:

> > OK, but if two nodes have a lot of free pages and the rest don't then
> > interleave will consume those free pages without performing any reclaim
> > from all the other nodes.  Hence hostpots or imbalances.
> > 
> > Whatever they are.  Why does it matter?
> 
> Hotspots create lots of requests going to the same numa node. The nodes 
> have a limited capability to service cacheline requests and the bandwidth 
> on the interlink is also limited. If too many processors request 
> information from the same remote node then performance will drop.

OK.

> There are different kind of data in a NUMA system:
> 
> Data that is node local is only accessed by the local processor. For node 
> local data we have no such concerns since the interlink is not used. Quite 
> a lot of kernel data per node or per cpu and thus is not a problem.
> 
> For shared data that is known to be performance critical--and where we 
> know that the data is accessed from multiple nodes--there we need to 
> balance the data between multiple nodes to avoid overloads and 
> to keep the system running at optimal speed. That is where interleave 
> becomes important.

But doesn't this patch introduce considerable risks of the above problems
occurring?  In the two-nodes-have-lots-of-free-memory scenario?

  reply	other threads:[~2006-11-06 21:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-03 20:58 Avoid allocating during interleave from almost full nodes Christoph Lameter
2006-11-03 21:46 ` Andrew Morton
2006-11-03 22:10   ` Christoph Lameter
2006-11-03 22:31     ` Andrew Morton
2006-11-04  0:28       ` Christoph Lameter
2006-11-04  0:58         ` Andrew Morton
2006-11-06 16:53           ` Christoph Lameter
2006-11-06 19:59             ` Andrew Morton
2006-11-06 20:12               ` Christoph Lameter
2006-11-06 20:24                 ` Andrew Morton
2006-11-06 20:31                   ` Christoph Lameter
2006-11-06 20:42                     ` Andrew Morton
2006-11-06 20:58                       ` Christoph Lameter
2006-11-06 21:20                         ` Andrew Morton [this message]
2006-11-06 21:42                           ` Christoph Lameter
2006-11-04  1:26       ` Paul Jackson
2006-11-04  1:42         ` Andrew Morton
2006-11-04 10:51           ` Paul Jackson
2006-11-06 16:56             ` Christoph Lameter
2006-11-08 10:21               ` Paul Jackson
2006-11-08 15:18                 ` Peter Zijlstra
2006-11-08 17:06                   ` Paul Jackson
2006-11-08 17:09                     ` Peter Zijlstra
2006-11-08 17:21                       ` Paul Jackson
2006-11-08 17:40                         ` Christoph Lameter
2006-12-01  7:51               ` Paul Jackson
2006-12-01  7:59                 ` Andrew Morton
2006-12-01 16:27                 ` Christoph Lameter
2006-11-04 10:35   ` CTL_UNNUMBERED and killing sys_sysctl Eric W. Biederman

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=20061106132029.28cd88b5.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.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.