linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: akpm@osdl.org, linux-mm@kvack.org
Subject: Re: [RFC] Avoid allocating interleave from almost full nodes
Date: Sat, 28 Oct 2006 17:59:27 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0610281741140.14058@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <200610272112.12118.ak@suse.de>

On Fri, 27 Oct 2006, Andi Kleen wrote:

> > Should we find that all nodes are marked as full then we disregard
> > the limit and allocate from the next node without any checks.
> 
> And when only one node is not full the interleaved allocations will
> all go to that node? I'm not sure that's a good idea.

It will go to that node until its filled up like the rest of the nodes. 
The intend of interleave is after all to even out allocations amoung all 
nodes and this follows that spirit.

> In general I think it's a bad hack: Who says the allocations
> of the process who filled a node is more important than the interleaving
> process? I think it would be better to keep them being equal citizens
> and allocate interleaving everywhere.

What currently happens is that we overallocate a node and we then fall 
back to a neighboring node. So we are already clustering the allocations
on particular nodes right now. But we are very rude right now and allocate 
from a node until its completely filled up. Processes running on the node
then either have to go off node for allocations or start reclaiming 
memory.

The patch avoids that situation as long as feasable by spreading to less 
filled nodes once we have reached the threshold.

The allocations of a process which does local allocations are more 
important since these are local allocations. This is data for exclusive 
use by that process. Interleave allocations are made for data that is 
shared between processes running on multiple nodes. For those allocations 
locality does matter less.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2006-10-29  0:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-28  2:46 Christoph Lameter
2006-10-28  4:12 ` Andi Kleen
2006-10-29  0:59   ` Christoph Lameter [this message]

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=Pine.LNX.4.64.0610281741140.14058@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox