> 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.
It isn't too difficult to add (although there maybe a catch somewhere).
All the caches are in a single linked list, guarded by a semaphore
(cache_chain_sem). So the ops would be;
1) Take the semaphore
2) Walk the list to find the cache
3) Unlink it
4) Update the reaping pointer (clock_searchp)
5) Drop the semaphore
6) Release the cache's memory
One reason this feature isn't implemented is my belief the slab allocator
should trap badly behaved code (or at least try its best, when the
detection code isn't too heavy).
Suppose an allocation from the cache is in progress when an attempt to
destory it occurs? Not legal, it is an indication that something is
wrong, but I won't want a system to fall over because of it. The
reason being the "fall over" could occur in a different part of the
system, making it difficult to debug.
Possible to guard against, but adds extra code (be it only a few
instructions) to the allocation path. Perhaps I'm trying to be too
defensive....
My current thought is at step 6) is to release all the memory
associated with the cache _except_ for the cache structure itself. Mark
it as deallocated, and put it on a free-list. When destroying a cache,
there may be allocated objects not freed (a bug in the consumer), and
keeping the cache struct around would allow later releasing of these objs
(accompied by warning messages). Cache structs on the free-list would be
re-used if there are no unreleased objects associated with it, but the
short time they are on the list would allow some races to be caught.
I'll try to add this to the current allocator sometime next week
(harass me if I don't).
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/