Messages in this thread | | | Date | Thu, 11 Feb 1999 07:41:07 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algorithm |
| |
On Thu, 11 Feb 1999, Mark Hemment wrote:
> 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/
| |