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

[Christoph Lameter <clameter@sgi.com>]

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?

> > 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.

> 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?
-
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/