linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@engr.sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@osdl.org
Subject: Re: [PATCH] NUMA policies in the slab allocator V2
Date: Fri, 18 Nov 2005 09:19:58 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.62.0511180911510.26812@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <200511180531.47764.ak@suse.de>

On Fri, 18 Nov 2005, Andi Kleen wrote:

> On Friday 18 November 2005 04:38, Christoph Lameter wrote:
> > You really want to run the useless fastpath? Examine lists etc for
> > the local node despite the policy telling you to get off node?
> 
> Yes.

And this is only the begining of the troubles with such an approach.

Lets say you do the fastpath, find that there are no local slab
entries available anymore and then consult policy. Policy tells you to 
interleave so you go to a different node and retrieve a slab entry from 
the slab list for that node (which is likely not to need to do any page 
allocation at all). Then this particular request has been fulfilled but 
there are still no local slab entries.

Then the interleave counter may have been incremented without 
allocating a page.

The next request would find no local slab entries available again and 
repeats the same dysfunctional behavior.

But lets say that there is another process running concurrently that uses 
default policy. It fills up the local slab entry cache. The task running 
with interleave policy will now start to ignore policy and use the slab 
entries generated by the page allocation of the other task.

Have a look at the slab allocator. I cannot imagine how you could make 
the approach work.

> > Hmm. Is a hugepage ever allocated from interrupt context?
> 
> They aren't.

Lets hope that it stays that way...

--
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:[~2005-11-18 17:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-18  1:51 Christoph Lameter
2005-11-18  2:59 ` Andi Kleen
2005-11-18  3:38   ` Christoph Lameter
2005-11-18  4:31     ` Andi Kleen
2005-11-18 17:19       ` 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.62.0511180911510.26812@schroedinger.engr.sgi.com \
    --to=clameter@engr.sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.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