From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Lameter <cl@linux-foundation.org>,
Nick Piggin <npiggin@suse.de>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
kamezawa.hiroyu@jp.fujitsu.com, lizf@cn.fujitsu.com,
mingo@elte.hu, yinghai@kernel.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31
Date: Thu, 18 Jun 2009 09:01:03 +0300 [thread overview]
Message-ID: <1245304863.12010.3.camel@penberg-laptop> (raw)
In-Reply-To: <1245295452.21602.42.camel@pasglop>
Hi Ben,
On Thu, 2009-06-18 at 13:24 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-06-18 at 12:00 +1000, Benjamin Herrenschmidt wrote:
> > > So I'm very much ok with the whole "use magic gfp_mask to indicate what
> > > works at what stage". And yes, I think it makes sense to extend it to the
> > > page allocator and might_sleep too, because GFP_KERNEL has all the same
> > > issues regardless of whether it's about page allocation or about slab
> > > allocators. And any "might_sleep" suppression really does tend to be about
> > > the exact same thing.
> >
> > Argh... still broken.
> >
> > In fact, my initial patch added it to the page allocator, which worked
> > for me. Pekka patch removed that and made it slab-only. So I'm blowing
> > up at boot in lockdep or so because I'm allocating page tables on
> > ppc32 with __get_free_pages() and GFP_KERNEL.
> >
> > I'll cook up a patch.
>
> Here it is:
>
> mm: Extend gfp masking to the page allocator
>
> The page allocator also needs the masking of gfp flags during boot,
> so this moves it out of slab/slub and uses it with the page allocator
> as well.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This will also make it easier to use it for limiting allocations that
> can block during suspend/resume, though doing this really fool-proof
> will require some kind of synchronization in set_gfp_allowed_mask()
> vs. allocations that have already started sleeping waiting for IOs.
>
> Index: linux-work/include/linux/gfp.h
> ===================================================================
> --- linux-work.orig/include/linux/gfp.h 2009-06-18 12:03:14.000000000 +1000
> +++ linux-work/include/linux/gfp.h 2009-06-18 12:08:21.000000000 +1000
> @@ -99,7 +99,7 @@ struct vm_area_struct;
> __GFP_NORETRY|__GFP_NOMEMALLOC)
>
> /* Control slab gfp mask during early boot */
> -#define SLAB_GFP_BOOT_MASK __GFP_BITS_MASK & ~(__GFP_WAIT|__GFP_IO|__GFP_FS)
> +#define GFP_BOOT_MASK __GFP_BITS_MASK & ~(__GFP_WAIT|__GFP_IO|__GFP_FS)
>
> /* Control allocation constraints */
> #define GFP_CONSTRAINT_MASK (__GFP_HARDWALL|__GFP_THISNODE)
> @@ -348,4 +348,11 @@ static inline void oom_killer_enable(voi
> oom_killer_disabled = false;
> }
>
> +extern gfp_t gfp_allowed_mask;
> +
> +static inline void set_gfp_allowed_mask(gfp_t mask)
> +{
> + gfp_allowed_mask = mask;
> +}
The only thing I don't like about this patch is that the caller gets to
decide which bits should be masked. I really think this should be a
mm_late_init() function that sets the mask _internally_ in the page
allocator.
But anyway, I am about to go completely off-line until Sunday or so
consider the approach:
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Pekka
next prev parent reply other threads:[~2009-06-18 6:01 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 13:25 [GIT PULL] Early SLAB fixes for 2.6.31 Pekka J Enberg
2009-06-12 13:38 ` Benjamin Herrenschmidt
2009-06-12 13:45 ` Pekka Enberg
2009-06-12 14:30 ` Christoph Lameter
2009-06-12 16:16 ` [GIT PULL v2] " Pekka J Enberg
2009-06-12 17:30 ` Christoph Lameter
2009-06-12 21:46 ` Benjamin Herrenschmidt
2009-06-15 6:46 ` Nick Piggin
2009-06-15 9:10 ` Pekka Enberg
2009-06-15 9:38 ` Nick Piggin
2009-06-15 14:43 ` Christoph Lameter
2009-06-14 7:12 ` Pekka J Enberg
2009-06-15 14:55 ` Christoph Lameter
2009-06-15 14:58 ` Pekka Enberg
2009-06-15 15:05 ` Christoph Lameter
2009-06-15 15:11 ` Pekka Enberg
2009-06-15 15:27 ` Pekka Enberg
2009-06-15 15:51 ` Christoph Lameter
2009-06-15 15:57 ` Pekka Enberg
2009-06-15 16:08 ` Christoph Lameter
2009-06-15 17:15 ` Linus Torvalds
2009-06-15 18:19 ` Pekka Enberg
2009-06-15 15:48 ` Christoph Lameter
2009-06-15 8:18 ` Heiko Carstens
2009-06-15 8:26 ` Nick Piggin
2009-06-15 8:32 ` Pekka Enberg
2009-06-15 8:52 ` Nick Piggin
2009-06-15 9:08 ` Pekka Enberg
2009-06-15 10:20 ` Heiko Carstens
2009-06-15 10:21 ` Pekka Enberg
2009-06-15 10:31 ` Nick Piggin
2009-06-15 10:36 ` Pekka Enberg
2009-06-15 9:10 ` Pekka Enberg
2009-06-15 9:41 ` Nick Piggin
2009-06-15 9:48 ` Pekka Enberg
2009-06-15 9:59 ` Nick Piggin
2009-06-15 9:51 ` Benjamin Herrenschmidt
2009-06-15 9:57 ` Pekka Enberg
2009-06-15 10:27 ` Nick Piggin
2009-06-15 10:45 ` Benjamin Herrenschmidt
2009-06-15 11:23 ` Nick Piggin
2009-06-15 12:38 ` Hugh Dickins
2009-06-15 13:07 ` Pekka Enberg
2009-06-16 4:57 ` Nick Piggin
2009-06-16 5:28 ` Benjamin Herrenschmidt
2009-06-16 5:36 ` Nick Piggin
2009-06-16 15:12 ` Christoph Lameter
2009-06-16 15:59 ` Nick Piggin
2009-06-15 21:31 ` Benjamin Herrenschmidt
2009-06-16 4:46 ` Nick Piggin
2009-06-16 5:18 ` Benjamin Herrenschmidt
2009-06-16 5:29 ` Nick Piggin
2009-06-16 18:45 ` Linus Torvalds
2009-06-17 7:47 ` Nick Piggin
2009-06-17 16:01 ` Linus Torvalds
2009-06-17 16:17 ` Nick Piggin
2009-06-17 21:39 ` Benjamin Herrenschmidt
2009-06-15 10:12 ` Nick Piggin
2009-06-15 10:39 ` Benjamin Herrenschmidt
2009-06-15 11:22 ` Nick Piggin
2009-06-15 11:28 ` Nick Piggin
2009-06-15 11:38 ` Nick Piggin
2009-06-15 21:37 ` Benjamin Herrenschmidt
2009-06-16 4:42 ` Nick Piggin
2009-06-15 21:32 ` Benjamin Herrenschmidt
2009-06-16 15:08 ` Christoph Lameter
2009-06-16 19:10 ` Linus Torvalds
2009-06-16 19:23 ` Christoph Lameter
2009-06-16 19:33 ` Linus Torvalds
2009-06-16 19:48 ` Christoph Lameter
2009-06-17 5:18 ` Pekka Enberg
2009-06-17 16:45 ` Linus Torvalds
2009-06-18 2:00 ` Benjamin Herrenschmidt
2009-06-18 3:24 ` Benjamin Herrenschmidt
2009-06-18 6:01 ` Pekka Enberg [this message]
2009-06-18 8:52 ` Benjamin Herrenschmidt
2009-06-16 21:58 ` Benjamin Herrenschmidt
2009-06-16 22:06 ` Linus Torvalds
2009-06-16 22:51 ` Benjamin Herrenschmidt
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=1245304863.12010.3.camel@penberg-laptop \
--to=penberg@cs.helsinki.fi \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux-foundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox