Re: [PATCH] signal_struct slab cache

[Mark Hemment]

Tigran,

> What about small (36 byte) things like fs_struct - looks like it is the
> only one left as kmalloc'd still - is there any point to convert it to a
> cache of its own - fs_cachep?
> 
> I understand it will come from 64 byte generic cache so perhaps it is just
> as wasteful? Or do you (SLAB) store some useful ctl info in those
> remaining bytes?

  Probably not worth it for fs_cachep.  But should be need investigated.

  My old slab allocator would fit a control struct behind the actual
object (in between the padding to an L1 bound).  With Manfred's changes, I
believe this to still be the case.

  The new allocator I'm working on will also fit the control struct
between objects (and at the end of a slab, and off-slab).  Plus, it will
allow different caches (with similar attributes) to share slabs - this is
only useful on low memory machines for caches which tend to have very few
allocations from them (say, the uid-cache, which takes up a full page for
only a few allocations on some system usage patterns - it would be
better off using one of the general sized caches - which is why I
originally implemented kmem_find_general_cachep()).

Mark