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 06:32:35PM -0700, Christoph Lameter wrote:
> On Tue, 8 May 2007, Matt Mackall wrote:
> 
> > 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.
> 
> New meaning in the last 3 years?

Whatever. I've already told you why it's a dontcare. I'm basically
done with this thread until some actual memory usage numbers are
injected into it.

> > > 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
> 
> So can SLUB.

Not without at least a bit per-object of overhead. So you can either
fit 512 objects in 4160 bytes or 504 objects in 4k.

> > importantly, it can put 2 1k objects and 16 128-byte objects on the
> > same page instead of on two pages.
> 
> That SLUB cannot do. And I do not believe you. SLOB must have some way to 
> distinguish the objects and their sizes since kfree does not include size 
> information. You can mix slabs of different size on the same page without 
> metadata. Magic?
> 
> So how does kfree then know how to free the object? There must be some way 
> where you get the metainformation. What is the point of your 8 byte 
> metadata that keeps getting inserted? That does not consume memory on a 
> page?

I've already explained this to you once tonight and there's only 8k of
code to read. It's also explained in the comment at the top:

 * SLAB is emulated on top of SLOB by simply calling constructors and
 * destructors for every SLAB allocation. Objects are returned with
 * the 8-byte alignment unless the SLAB_HWCACHE_ALIGN flag is
 * set, in which case the low-level allocator will fragment blocks to
 * create the proper alignment. Again, objects of page-size or greater
 * are allocated by calling __get_free_pages. As SLAB objects know
 * their size, no separate size bookkeeping is necessary and there is
 * essentially no allocation space overhead.

For the kmalloc case, we do have an 8-byte header, which works out to
be about 1/8th of the slop that mainline kmalloc over SLAB has on
average due to power of two cache sizes. So in both cases, less
overhead than SLAB and different-sized objects can be comingled. SLUB
would be awfully hard-pressed to have lower space overhead.

Compare:

void *kmem_cache_alloc(struct kmem_cache *c, gfp_t flags)
{
...
                b = slob_alloc(c->size, flags, c->align);
...
}

void kmem_cache_free(struct kmem_cache *c, void *b)
{
...
                slob_free(b, c->size);
...
}

vs.

void *__kmalloc(size_t size, gfp_t gfp)
{
...
                m = slob_alloc(size + SLOB_UNIT, gfp, 0);
                return m ? (void *)(m + 1) : 0;
...
}

void kfree(const void *block)
{
...
        slob_free((slob_t *)block - 1, 0);
...
}

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/