[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090526073813.GE21496@wotan.suse.de>
Date: Tue, 26 May 2009 09:38:13 +0200
From: Nick Piggin <npiggin@...e.de>
To: Pekka Enberg <penberg@...helsinki.fi>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>, Yinghai Lu <yinghai@...nel.org>,
Rusty Russell <rusty@...tcorp.com.au>,
"H. Peter Anvin" <hpa@...or.com>, Jeff Garzik <jgarzik@...ox.com>,
Alexander Viro <viro@....linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
cl@...ux-foundation.org, mpm@...enic.com
Subject: Re: [GIT PULL] scheduler fixes
On Mon, May 25, 2009 at 09:39:08PM +0300, Pekka Enberg wrote:
> Linus Torvalds wrote:
> >And vfs_caches_init_early() is actually doing some rather strange things,
> >like doing a "alloc_large_system_hash()" but not unconditionally: it does
> >it in the "late" initialization too, if not done early. inode_init_early
> >does soemthing very similar (ie a _conditional_ early init).
> >
> >So none of this seems to really get a huge advantage from the early init.
> >There seems to be some subtle NUMA issues, but do we really want that? I
> >get the feeling that nobody ever wanted to do it early, and then the NUMA
> >people said "I don't wnt to do this early, but I don't want to touch the
> >non-NUMA case, so I'll do it early for non-numa, and late for numa".
>
> SLUB does sysfs setup in kmem_cache_init() and if I saw some oopses if I
> don't call vfs_caches_init_early() first. I didn't look too closely, though.
Did you also test the NUMA/hashdist case? vfs_caches_init_early doesn't
do much in that case.
I would say it is much more robust to do sysfs setup later if we move
the slab setup so early. Probably it is just quite lucky not to explode
in the !numa case because the vfs needs quite a bit of setting up...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists