From: Nick Piggin <npiggin@suse.de>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, cl@linux-foundation.org,
kamezawa.hiroyu@jp.fujitsu.com, lizf@cn.fujitsu.com,
mingo@elte.hu, yinghai@kernel.org, benh@kernel.crashing.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31
Date: Mon, 15 Jun 2009 10:52:09 +0200 [thread overview]
Message-ID: <20090615085209.GB30964@wotan.suse.de> (raw)
In-Reply-To: <1245054779.23207.6.camel@penberg-laptop>
Hi Pekka,
On Mon, Jun 15, 2009 at 11:32:59AM +0300, Pekka Enberg wrote:
> Hi Nick,
>
> On Mon, 2009-06-15 at 10:26 +0200, Nick Piggin wrote:
> > >
> > > Might be that I missed something. Maybe some special flag?
> >
> > No, just a bug in the conversion.
> >
> > If you predicate the schedule_work call on slab_state == SYSFS, then
> > it should work (when sysfs comes up later in init, previously added
> > slabs will be registered with sysfs).
> >
> > Oh, and you'd need to also not pass __SYSFS_ADD_DEFERRED into
> > kmem_cache_create in that case too.
>
> I am not sure I follow you here. We are setting up slab so early that we
> absolutely _must_ defer sysfs setup. But we're also setting up slab much
> earlier than workqueues, so we shouldn't really do schedule_work() at
> that point.
There's 2 types of deferring going on here. In early boot we
obviously don't touch sysfs at all. All other times, we still
need to defer because we don't know the context it is being
called from.
> Furthermore, early boot cache sysfs setup is explicitly
> handled in slab_sysfs_init() so I think we need something like the patch
> below?
I don't think so because keventd probably comes up before sysfs
still is ready (in this respect the existing pre-early-slab code
is probably still broken but just never done such early DMA
allocations). So it just makes sense to do it all via the slab_state
flag.
Also, if you keep the deferred flag on there for early created
slabs, then the next sysfs_add_work will try to add it again
(after slab_sysfs_init already added it).
Here
---
mm/slub.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -2596,6 +2596,7 @@ static noinline struct kmem_cache *dma_k
struct kmem_cache *s;
char *text;
size_t realsize;
+ unsigned long slabflags;
s = kmalloc_caches_dma[index];
if (s)
@@ -2617,9 +2618,18 @@ static noinline struct kmem_cache *dma_k
(unsigned int)realsize);
s = kmalloc(kmem_size, flags & ~SLUB_DMA);
+ /*
+ * Must defer sysfs creation to a workqueue because we don't know
+ * what context we are called from. Before sysfs comes up, we don't
+ * need to do anything because slab_sysfs_init will start by
+ * adding all existing slabs to sysfs.
+ */
+ slabflags = SLAB_CACHE_DMA;
+ if (slab_state >= SYSFS)
+ slabflags |= __SYSFS_ADD_DEFERRED;
+
if (!s || !text || !kmem_cache_open(s, flags, text,
- realsize, ARCH_KMALLOC_MINALIGN,
- SLAB_CACHE_DMA|__SYSFS_ADD_DEFERRED, NULL)) {
+ realsize, ARCH_KMALLOC_MINALIGN, slabflags, NULL)) {
kfree(s);
kfree(text);
goto unlock_out;
@@ -2628,7 +2638,8 @@ static noinline struct kmem_cache *dma_k
list_add(&s->list, &slab_caches);
kmalloc_caches_dma[index] = s;
- schedule_work(&sysfs_add_work);
+ if (slab_state >= SYSFS)
+ schedule_work(&sysfs_add_work);
unlock_out:
up_write(&slub_lock);
next prev parent reply other threads:[~2009-06-15 8:52 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 13:25 [GIT PULL] " 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 [this message]
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
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=20090615085209.GB30964@wotan.suse.de \
--to=npiggin@suse.de \
--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=penberg@cs.helsinki.fi \
--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
all inboxes | Powered by JetHome®