Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree

[Matt Mackall <mpm@selenic.com>]

On Tue, May 08, 2007 at 05:51:27PM -0700, Christoph Lameter wrote:
> On Tue, 8 May 2007, Matt Mackall wrote:
> 
> > First, SLOB no longer runs on SMP because SLAB grew some RCU-related
> > hair. So it now effectively has no locks at all! 
> 
> Well it seems that SLOB was not well maintained. RCU has been around for a 
> long time and SLOB has not been updated to cope with it.

RCU's incursion into SLAB that broke SLOB is relatively new. And it
only broke for people using SMP or SPARSEMEM. Intersection with target
audience of SLOB: ~0.
  
> > Third, I don't think it's possible even in theory for a SLAB-like
> > allocator to be as efficient as SLOB simply due to the constraints of
> > putting only objects of the same size on a given page. So consider me
> > skeptical on the density claim.
> 
> SLUB can put 32 objects sized 128 byte each in a 4k page. Can SLOB do 
> the same?

Yes. It can in fact put 512 8-byte objects in a 4k page. More
importantly, it can put 2 1k objects and 16 128-byte objects on the
same page instead of on two pages.

> > It is usually better to use SLUB simply because you're more likely to
> > have 1GB of RAM rather than 4MB.
> 
> SLUB should be perfectly fine for that environment provided you 
> adjust the cacheline alignment and switch off SLUB debugging. 
> define L1_CACHE_BYTES to be 4 or so.

Perhaps. We'll need to look at some numbers.

-- 
Mathematics is the supreme nostalgia of our time.