Messages in this thread | | | From | Ed Tomlinson <> | Subject | Re: [PATCH 2/2] move slab pages to the lru, for 2.5.27 | Date | Sun, 21 Jul 2002 09:33:01 -0400 |
| |
On July 21, 2002 07:24 am, Craig Kulesa wrote:
> This patch is intermediate between where we were (freeing slab caches > blindly and not in tune with the rest of the VM), and where we want to be > (cache pruning by page as we scan the active list looking for cold pages > to deactivate). Uhhh, well, I *think* that's where we want to be. :) > > How do we get there? > > Given a slab page, I can find out what cachep and slab I'm dealing with > (via GET_PAGE_SLAB and friends). If the cache is prunable one, > cachep->pruner tells me what kind of callback (dcache/inode/dquot) I > should invoke to prune the page. No problem. > > The trouble comes when we try to replace shrink_dcache_memory() and > friends with slab-aware pruners. Namely, how to teach those > inode/dcache/dquot callbacks to free objects belonging to a *specified* > page or slab? If I have a dentry slab, I'd like to try to liberate > *those* dentries, not some random ones like shrink_dcache_memory does now.
Well not quite random. It prunes the oldest entries. The idea behind the prunable callback is that some caches have specific aging methods. What I tried to do here was keep the rate of aging in sync with the VM.
> I'm still trying to figure out how to make that work. Or is that > totally the wrong approach? Thoughts? ;)
Thats a question I have asked myself too. What could be done is, scan the entries in the slab encountered, using a call back, free them if they are purgeable. If this ends up producing an empty slab, release it.
>Intermezzo has a funky dentry cache that may need a pruner method (??), >but I didn't touch it. If there was a better way to do this, I was too >blind to see it.
Looking at the Intermezzo dcache code, I think you made the right choise. I do not think this needs a pruner method.
Ed Tomlinson
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |