All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use numa policy API for boot time policy
Date: Sat, 5 Jun 2004 12:33:19 +0200	[thread overview]
Message-ID: <20040605123319.14b8ca17.ak@suse.de> (raw)
In-Reply-To: <40C19E85.7090809@colorfullife.com>

On Sat, 05 Jun 2004 12:20:53 +0200
Manfred Spraul <manfred@colorfullife.com> wrote:

> Andi Kleen wrote:
> 
> >On Sat, 05 Jun 2004 03:56:53 +0200
> >Manfred Spraul <manfred@colorfullife.com> wrote:
> >  
> >
> >>Does it work for order != 0 allocations? It's important that the big 
> >>hash tables do not end up all in node 0. AFAICS alloc_pages_current() 
> >>calls interleave_nodes() only for order==0 allocs.
> >>    
> >>
> >
> >That's correct. It will only work for order 0 allocations.
> >
> >  
> >
> What's the purpose of the "&& order == 0)" test for MPOL_INTERLEAVE in 
> alloc_pages_current?
> What would break if it's removed?

Nothing. Just the interleaving will not be very good.
Just the vma interleaving relies on order 0 right now.

But I would really try to use vmalloc() for this. In fact you don't
even need vmalloc_interleaved(), because the normal vmalloc allocation
together with the interleave policy should do the right thing.

> 
> And what about in_interrupt() allocations? During boot everything should 
> be interleaved - I'd modify default_policy to MPOL_INTERLEAVE instead of 
> setting process affinity.

Better don't do that. It may break some subtle assumptions.

I guess the in_interrupt() allocations will have to live with that.
They should be relatively rare.

In theory you could add a system_state == SYSTEM_BOOTING check again,
but polluting the fast path for this would be imho overkill.

-Andi
 

      reply	other threads:[~2004-06-05 10:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-05  1:43 [PATCH] Use numa policy API for boot time policy Andi Kleen
2004-06-05  1:56 ` Manfred Spraul
2004-06-05  2:18   ` Andi Kleen
2004-06-05  2:32     ` Anton Blanchard
2004-06-05 10:22       ` Andi Kleen
2004-06-05 10:48         ` Andi Kleen
2004-06-09 15:44         ` Anton Blanchard
2004-06-09 15:56           ` Andi Kleen
2004-06-09 16:12             ` Anton Blanchard
2004-06-05 10:20     ` Manfred Spraul
2004-06-05 10:33       ` Andi Kleen [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=20040605123319.14b8ca17.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.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.