[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0705031744560.15240@schroedinger.engr.sgi.com>
Date: Thu, 3 May 2007 17:54:26 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc: Hugh Dickins <hugh@...itas.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Mackerras <paulus@...ba.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: 2.6.22 -mm merge plans: slub on PowerPC
On Fri, 4 May 2007, Benjamin Herrenschmidt wrote:
> > The SLUB allocator relies on struct page fields first_page and slab,
> > overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot then
> > be used for the lowest level of pagetable pages. This was obstructing
> > SLUB on PowerPC, which uses kmem_caches for its pagetables. So convert
> > its pte level to use quicklist pages (whereas pmd, pud and 64k-page pgd
> > want partpages, so continue to use kmem_caches for pmd, pud and pgd).
> > But to keep up appearances for pgtable_free, we still need PTE_CACHE_NUM.
>
> Interesting... I'll have a look asap.
I would also recommend looking at removing the constructors for the
remaining slabs. A constructor requires that SLUB never touch the object
(same situation as is resulting from enabling debugging). So it must
increase the object size in order to put the free pointer after the
object. In case of a order of 2 cache this has a particularly bad effect
of doubling object size. If the objects can be overwritten on free (no
constructor) then we can use the first word of the object as a freepointer
on kfree. Meaning we can use a hot cacheline so no cache miss. On
alloc we have already touched the first cacheline which also avoids a
cacheline fetch there. This is the optimal way of operation for SLUB.
Hmmm.... We could add an option to allow the use of a constructor while
keeping the free pointer at the beginning of the object? Then we would
have to zap the first word on alloc. Would work like quicklists.
Add SLAB_FREEPOINTER_MAY_OVERLAP?
-
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