On Mon, Apr 07 2008 at 12:52 +0300, Pekka J Enberg <penberg@xxxxxxxxxxxxxx> wrote: > Hi Boaz, > > On Mon, 7 Apr 2008, Boaz Harrosh wrote: >> The slub behavior described above is disturbing. If I want a 128-byte kmalloc I >> would use kmalloc. But if I want a dedicated kmem_cache of my own I take the trouble >> to create one. As I understood it, a dedicated kmem_cache is somewhat growing but >> lazy-shrinking and eventually maxes out to my usage of it. If I reserve one elemnt then >> even when memory is low and caches are shrunk I have at least a page. But more then >> In low memory condition, in a steady sate the cost of each allocation is kept low >> because I have the pages for my self and I don't need to go grabbing global locks. >> Sharing with other pools breaks that behavior. Perhaps we need a flag in kmem_cache >> creation that says we do not want slab sharing (OK slub sharing in this case). > > I think you're better off using the page allocator then. SLOB, for > example, doesn't guarantee you're the only user of a page for > kmem_cache_alloc() either and I don't really see why it should as it tries > to be as memory efficient as possible. > > Pekka Please forgive my ignorance, but what is then the difference between kmem_cache_alloc() and kmalloc? would you not agree that sometimes we want to override that sharing of SLOBs? Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
