* Re: [git pull] vfs.git bits and pieces
[not found] ` <20131120144014.386293ce24e7b298ebab7b8e@linux-foundation.org>
@ 2013-11-21 11:19 ` Kirill A. Shutemov
0 siblings, 0 replies; only message in thread
From: Kirill A. Shutemov @ 2013-11-21 11:19 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Al Viro, Kirill A. Shutemov, Linux Kernel Mailing List,
linux-fsdevel, Ingo Molnar, Peter Zijlstra, linux-mm
Andrew Morton wrote:
> On Wed, 20 Nov 2013 14:33:35 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Wed, Nov 20, 2013 at 9:47 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > BTW, something odd happened to mm/memory.c - either a mangled patch
> > > or a lost followup:
> > >
> > > commit ea1e7ed33708
> > > mm: create a separate slab for page->ptl allocation
> > >
> > > Fair enough, and yes, it does create that separate slab. The problem is,
> > > it's still using kmalloc/kfree for those beasts - page_ptl_cachep isn't
> > > used at all...
> >
> > Ok, it looks straightforward enough to just replace the kmalloc/kfree
> > with using a slab allocation using the page_ptl_cachep pointer. I'd do
> > it myself, but I would like to know how it got lost? Also, much
> > testing to make sure the cachep is initialized early enough.
>
> agh, I went through hell keeping that patch alive and it appears I lost
> some of it.
Actually, I've lost it while adding BLOATED_SPINLOCKS :(
> > Or should we just revert the commit that added the pointless/unused
> > slab pointer?
> >
> > Andrew, Kirill, comments?
>
> Let's just kill it please. We can try again for 3.14.
I'm okay with that.
Only side note: it's useful not only for debug case, but also for
PREEMPT_RT where spinlock_t is always bloated.
Fixed patch:
^ permalink raw reply [flat|nested] only message in thread