From: Pavel Machek <pavel@ucw.cz>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, mingo@elte.hu,
npiggin@suse.de, benh@kernel.crashing.org,
akpm@linux-foundation.org, cl@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: [PATCH v2] slab,slub: ignore __GFP_WAIT if we're booting or suspending
Date: Fri, 19 Jun 2009 16:59:13 +0200 [thread overview]
Message-ID: <20090619145913.GA1389@ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.64.0906121201490.30049@melkki.cs.Helsinki.FI>
Hi!
>
> As explained by Benjamin Herrenschmidt:
>
> Oh and btw, your patch alone doesn't fix powerpc, because it's missing
> a whole bunch of GFP_KERNEL's in the arch code... You would have to
> grep the entire kernel for things that check slab_is_available() and
> even then you'll be missing some.
>
> For example, slab_is_available() didn't always exist, and so in the
> early days on powerpc, we used a mem_init_done global that is set form
> mem_init() (not perfect but works in practice). And we still have code
> using that to do the test.
>
> Therefore, ignore __GFP_WAIT in the slab allocators if we're booting or
> suspending.
Ok... GFP_KERNEL allocations normally don't fail; now they
will. Should we at least force access to atomic reserves in such case?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, mingo@elte.hu,
npiggin@suse.de, benh@kernel.crashing.org,
akpm@linux-foundation.org, cl@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: [PATCH v2] slab,slub: ignore __GFP_WAIT if we're booting or suspending
Date: Fri, 19 Jun 2009 16:59:13 +0200 [thread overview]
Message-ID: <20090619145913.GA1389@ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.64.0906121201490.30049@melkki.cs.Helsinki.FI>
Hi!
>
> As explained by Benjamin Herrenschmidt:
>
> Oh and btw, your patch alone doesn't fix powerpc, because it's missing
> a whole bunch of GFP_KERNEL's in the arch code... You would have to
> grep the entire kernel for things that check slab_is_available() and
> even then you'll be missing some.
>
> For example, slab_is_available() didn't always exist, and so in the
> early days on powerpc, we used a mem_init_done global that is set form
> mem_init() (not perfect but works in practice). And we still have code
> using that to do the test.
>
> Therefore, ignore __GFP_WAIT in the slab allocators if we're booting or
> suspending.
Ok... GFP_KERNEL allocations normally don't fail; now they
will. Should we at least force access to atomic reserves in such case?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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-19 14:59 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 8:13 [PATCH 2/2] slab,slub: ignore __GFP_WAIT if we're booting or suspending Pekka J Enberg
2009-06-12 8:13 ` Pekka J Enberg
2009-06-12 9:03 ` [PATCH v2] " Pekka J Enberg
2009-06-12 9:03 ` Pekka J Enberg
2009-06-12 9:10 ` Ingo Molnar
2009-06-12 9:10 ` Ingo Molnar
2009-06-12 9:21 ` Benjamin Herrenschmidt
2009-06-12 9:21 ` Benjamin Herrenschmidt
2009-06-12 9:24 ` Pekka Enberg
2009-06-12 9:24 ` Pekka Enberg
2009-06-12 9:36 ` Benjamin Herrenschmidt
2009-06-12 9:36 ` Benjamin Herrenschmidt
2009-06-12 9:45 ` Pekka J Enberg
2009-06-12 9:45 ` Pekka J Enberg
2009-06-12 9:58 ` Benjamin Herrenschmidt
2009-06-12 9:58 ` Benjamin Herrenschmidt
2009-06-12 10:00 ` Pekka Enberg
2009-06-12 10:00 ` Pekka Enberg
2009-06-12 15:22 ` Andrew Morton
2009-06-12 15:22 ` Andrew Morton
2009-06-12 9:49 ` Pekka Enberg
2009-06-12 9:49 ` Pekka Enberg
2009-06-12 9:52 ` Nick Piggin
2009-06-12 9:52 ` Nick Piggin
2009-06-12 9:54 ` Pekka Enberg
2009-06-12 9:54 ` Pekka Enberg
2009-06-12 9:59 ` Benjamin Herrenschmidt
2009-06-12 9:59 ` Benjamin Herrenschmidt
2009-06-25 4:38 ` Nick Piggin
2009-06-25 4:38 ` Nick Piggin
2009-06-12 10:07 ` Ingo Molnar
2009-06-12 10:07 ` Ingo Molnar
2009-06-12 10:11 ` Pekka Enberg
2009-06-12 10:11 ` Pekka Enberg
2009-06-12 10:15 ` Nick Piggin
2009-06-12 10:15 ` Nick Piggin
2009-06-12 10:30 ` Pekka J Enberg
2009-06-12 10:30 ` Pekka J Enberg
2009-06-12 10:32 ` Pekka Enberg
2009-06-12 10:32 ` Pekka Enberg
2009-06-12 15:16 ` Linus Torvalds
2009-06-12 15:16 ` Linus Torvalds
2009-06-12 15:16 ` Pekka Enberg
2009-06-12 15:16 ` Pekka Enberg
2009-06-12 11:13 ` Benjamin Herrenschmidt
2009-06-12 11:13 ` Benjamin Herrenschmidt
2009-06-12 11:24 ` Benjamin Herrenschmidt
2009-06-12 11:24 ` Benjamin Herrenschmidt
2009-06-12 11:11 ` Benjamin Herrenschmidt
2009-06-12 11:11 ` Benjamin Herrenschmidt
2009-06-12 11:34 ` Pekka Enberg
2009-06-12 11:34 ` Pekka Enberg
2009-06-12 11:41 ` Benjamin Herrenschmidt
2009-06-12 11:41 ` Benjamin Herrenschmidt
2009-06-12 11:43 ` Pekka Enberg
2009-06-12 11:43 ` Pekka Enberg
2009-06-12 15:30 ` Andrew Morton
2009-06-12 15:30 ` Andrew Morton
2009-06-12 21:42 ` Benjamin Herrenschmidt
2009-06-12 21:42 ` Benjamin Herrenschmidt
2009-06-25 4:41 ` Nick Piggin
2009-06-25 4:41 ` Nick Piggin
2009-06-12 11:09 ` Benjamin Herrenschmidt
2009-06-12 11:09 ` Benjamin Herrenschmidt
2009-06-12 15:04 ` Linus Torvalds
2009-06-12 15:04 ` Linus Torvalds
2009-06-12 15:05 ` Pekka Enberg
2009-06-12 15:05 ` Pekka Enberg
2009-06-19 14:59 ` Pavel Machek [this message]
2009-06-19 14:59 ` Pavel Machek
2009-06-19 22:27 ` Benjamin Herrenschmidt
2009-06-19 22:27 ` Benjamin Herrenschmidt
2009-06-19 23:23 ` Pavel Machek
2009-06-19 23:23 ` Pavel Machek
2009-06-19 23:50 ` Benjamin Herrenschmidt
2009-06-19 23:50 ` Benjamin Herrenschmidt
2009-06-20 0:28 ` Pavel Machek
2009-06-20 0:28 ` Pavel Machek
2009-06-20 2:10 ` Benjamin Herrenschmidt
2009-06-20 2:10 ` Benjamin Herrenschmidt
2009-06-21 6:18 ` Pavel Machek
2009-06-21 6:18 ` Pavel Machek
2009-06-21 9:31 ` Benjamin Herrenschmidt
2009-06-21 9:31 ` Benjamin Herrenschmidt
2009-06-25 4:34 ` Nick Piggin
2009-06-25 4:34 ` Nick Piggin
2009-06-25 9:56 ` Benjamin Herrenschmidt
2009-06-25 9:56 ` 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=20090619145913.GA1389@ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.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.