Messages in this thread | | | Date | Mon, 7 Aug 2000 15:47:25 +0100 (BST) | From | Mark Hemment <> | Subject | Re: [PATCH] signal_struct slab cache |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |