From: Craig Kulesa <ckulesa@as.arizona.edu>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Subject: [PATCH 2/2] move slab pages to the lru, for 2.5.27
Date: Sun, 21 Jul 2002 04:24:55 -0700 (MST) [thread overview]
Message-ID: <Pine.LNX.4.44.0207210245080.6770-100000@loke.as.arizona.edu> (raw)
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next reply other threads:[~2002-07-21 11:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-21 11:24 Craig Kulesa [this message]
2002-07-21 21:31 ` William Lee Irwin III
2002-07-22 7:08 ` Craig Kulesa
2002-07-22 18:54 ` Steven Cole
2002-07-22 22:21 ` William Lee Irwin III
2002-07-22 22:36 ` Craig Kulesa
2002-07-23 4:36 ` William Lee Irwin III
2002-07-23 14:31 ` Steven Cole
2002-07-24 20:28 ` Steven Cole
2002-07-24 21:02 ` Steven Cole
[not found] <200207210933.01211.tomlins@cam.org>
2002-07-21 21:24 ` Craig Kulesa
2002-07-21 23:15 ` Ed Tomlinson
[not found] <200207242012.59150.tomlins@cam.org>
2002-07-25 12:00 ` Craig Kulesa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44.0207210245080.6770-100000@loke.as.arizona.edu \
--to=ckulesa@as.arizona.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox