> Alexander,
>
> On Thu, 11 Feb 1999, Alexander Viro wrote:
> > BTW, is there a decent way to create a cache from module? slabs
> > want permanent storage, if I've parsed the comment in mm/slab.c right. I
> > really need it for clean rewrite of FAT-derived stuff (cache for directory
> > entries in FAT sense; that would solve all problems with bogus inumbers).
>
> Slab caches cannot be destroyed, but they can be shrunk
> (kmem_cache_shrink()). There were too many conditions to be handed to
> allow destroying (extra, protective, locking in performance critical code
> paths).
> For modules, my thoughts were that only the cache ptrs (kmem_cache_t *)
> would need to always be resident. When a module is loaded it would check
> its cache ptrs (against NULL) to see if they needed creating. On unload,
> it shrinks the caches.
Mark, sorry, but requiring modules to *have* a resident part is what
makes life unpleasant. I know about kmem_cache_shrink(), indeed. Think of
modules debugging, where you may have the size of cache elements changing
across the rmmod/insmod and definitely do not want to reboot after
recompiling. And keeping stubs for all filesystems would be ugly.
How serious are problems with destroying a totally shrinked slab?
*This* part may be as slow as it wants - it isn't something speed-critical.
> I know the Slab allocator needs a clean-up. I'm working on a
> replacment, which has per-engine (per-cpu) lists fronting the back SLABS
> (this is for SMP performance, and ensures re-use of the most likely h/w
> cache hot object). Being able to remove a cache entirely is on my list
> of features.
Fine. For the time being I'll simply use kmalloc/kfree.
-
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/