Messages in this thread | | | Date | Wed, 09 May 2007 12:43:11 +1000 | From | Nick Piggin <> | Subject | Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree |
| |
Christoph Lameter wrote: > On Tue, 8 May 2007, Matt Mackall wrote: > > >>>>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. > > > Slub uses a linked list pointer in the page struct which is NULL if all > objects are allocated. There is no bit per object 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 > > > Exactly. That overhead does not exist in SLUB. Thus SLOB is less efficient > than SLUB.
What you trade for that is that one page page can only serve one slab. For small systems, I would not be surprised if that was less space efficient, even just looking at kmalloc caches in isolation. Or do you have numbers to support your conclusion?
-- SUSE Labs, Novell Inc. - 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/
| |