From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
mingo@elte.hu, akpm@linux-foundation.org, npiggin@suse.de
Subject: Re: slab: setup allocators earlier in the boot sequence
Date: Sat, 13 Jun 2009 00:02:50 +1000 [thread overview]
Message-ID: <1244815370.7172.169.camel@pasglop> (raw)
In-Reply-To: <1244814852.30512.67.camel@penberg-laptop>
On Fri, 2009-06-12 at 16:54 +0300, Pekka Enberg wrote:
> Hi Christoph,
>
> On Fri, 2009-06-12 at 09:49 -0400, Christoph Lameter wrote:
> > Best thing to do is to recognize the fact that we are still in early boot
> > in the allocators. Derived allocators (such as slab and vmalloc) mask bits
> > using GFP_RECLAIM_MASK and when doing allocations through the page
> > allocator. You could make GFP_RECLAIM_MASK a variable. During boot
> > __GFP_WAIT would not be set in GFP_RECLAIM_MASK.
>
> Ben's patch does something like that and I have patches that do that
> floating around too.
>
> The problem here is that it's not enough that we make GFP_RECLAIM_MASK a
> variable. There are various _debugging checks_ that happen much earlier
> than that. We need to mask out those too which adds overhead to
> kmalloc() fastpath, for example.
Hrm... I though I stuck my masking before the lockdep tests but maybe I
missed some...
Again, I'm not saying my patch is the best way to solve it. My point is
more that the callers shouldn't have to bother. (And thus the WARN_ON
isn't right :-)
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
mingo@elte.hu, akpm@linux-foundation.org, npiggin@suse.de
Subject: Re: slab: setup allocators earlier in the boot sequence
Date: Sat, 13 Jun 2009 00:02:50 +1000 [thread overview]
Message-ID: <1244815370.7172.169.camel@pasglop> (raw)
In-Reply-To: <1244814852.30512.67.camel@penberg-laptop>
On Fri, 2009-06-12 at 16:54 +0300, Pekka Enberg wrote:
> Hi Christoph,
>
> On Fri, 2009-06-12 at 09:49 -0400, Christoph Lameter wrote:
> > Best thing to do is to recognize the fact that we are still in early boot
> > in the allocators. Derived allocators (such as slab and vmalloc) mask bits
> > using GFP_RECLAIM_MASK and when doing allocations through the page
> > allocator. You could make GFP_RECLAIM_MASK a variable. During boot
> > __GFP_WAIT would not be set in GFP_RECLAIM_MASK.
>
> Ben's patch does something like that and I have patches that do that
> floating around too.
>
> The problem here is that it's not enough that we make GFP_RECLAIM_MASK a
> variable. There are various _debugging checks_ that happen much earlier
> than that. We need to mask out those too which adds overhead to
> kmalloc() fastpath, for example.
Hrm... I though I stuck my masking before the lockdep tests but maybe I
missed some...
Again, I'm not saying my patch is the best way to solve it. My point is
more that the callers shouldn't have to bother. (And thus the WARN_ON
isn't right :-)
Cheers,
Ben.
--
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>
next prev parent reply other threads:[~2009-06-12 14:04 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906111959.n5BJxFj9021205@hera.kernel.org>
2009-06-12 1:29 ` slab: setup allocators earlier in the boot sequence Benjamin Herrenschmidt
2009-06-12 1:30 ` Benjamin Herrenschmidt
2009-06-12 3:56 ` Benjamin Herrenschmidt
2009-06-12 4:25 ` Benjamin Herrenschmidt
2009-06-12 5:07 ` Benjamin Herrenschmidt
2009-06-12 5:07 ` Benjamin Herrenschmidt
2009-06-12 6:16 ` Pekka J Enberg
2009-06-12 6:16 ` Pekka J Enberg
2009-06-12 7:34 ` Benjamin Herrenschmidt
2009-06-12 7:34 ` Benjamin Herrenschmidt
2009-06-12 7:39 ` Benjamin Herrenschmidt
2009-06-12 7:39 ` Benjamin Herrenschmidt
2009-06-12 7:47 ` Pekka Enberg
2009-06-12 7:47 ` Pekka Enberg
2009-06-12 8:17 ` Pekka Enberg
2009-06-12 8:17 ` Pekka Enberg
2009-06-12 8:47 ` Benjamin Herrenschmidt
2009-06-12 8:47 ` Benjamin Herrenschmidt
2009-06-12 7:45 ` Pekka Enberg
2009-06-12 7:45 ` Pekka Enberg
2009-06-12 7:54 ` Nick Piggin
2009-06-12 7:54 ` Nick Piggin
2009-06-12 7:59 ` Pekka Enberg
2009-06-12 7:59 ` Pekka Enberg
2009-06-12 8:02 ` Nick Piggin
2009-06-12 8:02 ` Nick Piggin
2009-06-12 8:04 ` Pekka Enberg
2009-06-12 8:04 ` Pekka Enberg
2009-06-12 8:20 ` Nick Piggin
2009-06-12 8:20 ` Nick Piggin
2009-06-12 8:44 ` Benjamin Herrenschmidt
2009-06-12 8:44 ` Benjamin Herrenschmidt
2009-06-12 8:49 ` Pekka Enberg
2009-06-12 8:49 ` Pekka Enberg
2009-06-12 9:13 ` Nick Piggin
2009-06-12 9:13 ` Nick Piggin
2009-06-12 9:24 ` Benjamin Herrenschmidt
2009-06-12 9:24 ` Benjamin Herrenschmidt
2009-06-12 9:30 ` Nick Piggin
2009-06-12 9:30 ` Nick Piggin
2009-06-12 9:44 ` Benjamin Herrenschmidt
2009-06-12 9:44 ` Benjamin Herrenschmidt
2009-06-12 9:49 ` Nick Piggin
2009-06-12 9:49 ` Nick Piggin
2009-06-12 8:44 ` Benjamin Herrenschmidt
2009-06-12 8:44 ` Benjamin Herrenschmidt
2009-06-12 8:42 ` Benjamin Herrenschmidt
2009-06-12 8:42 ` Benjamin Herrenschmidt
2009-06-12 8:40 ` Benjamin Herrenschmidt
2009-06-12 8:40 ` Benjamin Herrenschmidt
2009-06-12 8:43 ` Pekka Enberg
2009-06-12 8:43 ` Pekka Enberg
2009-06-12 8:53 ` Benjamin Herrenschmidt
2009-06-12 8:53 ` Benjamin Herrenschmidt
2009-06-12 9:05 ` Pekka Enberg
2009-06-12 9:05 ` Pekka Enberg
2009-06-12 9:14 ` Nick Piggin
2009-06-12 9:14 ` Nick Piggin
2009-06-12 9:07 ` Pekka Enberg
2009-06-12 9:07 ` Pekka Enberg
2009-06-12 13:49 ` Christoph Lameter
2009-06-12 13:49 ` Christoph Lameter
2009-06-12 13:54 ` Pekka Enberg
2009-06-12 13:54 ` Pekka Enberg
2009-06-12 14:02 ` Benjamin Herrenschmidt [this message]
2009-06-12 14:02 ` Benjamin Herrenschmidt
2009-06-12 14:04 ` Pekka Enberg
2009-06-12 14:04 ` Pekka Enberg
2009-06-12 14:07 ` Christoph Lameter
2009-06-12 14:07 ` Christoph Lameter
2009-06-12 14:00 ` Benjamin Herrenschmidt
2009-06-12 14:00 ` Benjamin Herrenschmidt
2009-06-12 13:44 ` Christoph Lameter
2009-06-12 13:44 ` Christoph Lameter
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=1244815370.7172.169.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.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.