This is an update for the 2.5 port of Ed Tomlinson's patch to move slab
pages onto the lru for page aging, atop 2.5.27 and the full rmap patch.
It is aimed at being a fairer, self-tuning way to target and evict slab
pages.
Previous description:
http://mail.nl.linux.org/linux-mm/2002-07/msg00216.html
Patch URL:
http://loke.as.arizona.edu/~ckulesa/kernel/rmap-vm/2.5.27/
What's next:
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.
I'm still trying to figure out how to make that work. Or is that
totally the wrong approach? Thoughts? ;)
[I understand Rik's working on this, but my curiosity made me ask anyway!]
Comments, fixes, & feedback always welcome. :)
Craig Kulesa
Steward Obs.
Univ. of Arizona
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:35 EST