From: Craig Kulesa <ckulesa@as.arizona.edu>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] move slab pages to the lru, for 2.5.27
Date: Mon, 22 Jul 2002 00:08:00 -0700 (MST) [thread overview]
Message-ID: <Pine.LNX.4.44.0207212340530.13407-100000@loke.as.arizona.edu> (raw)
In-Reply-To: <20020721213131.GA919@holomorphy.com>
On Sun, 21 Jul 2002, William Lee Irwin III wrote:
> Can you test this to verify that reclamation is actually done?
Looks like it is. I have a script that does slocate, loads monstrous
blank images into gimp, manipulates it to drive the machine to swap,
performs a 'find' to test and make sure we haven't evicted slab pages too
readily, loads some addn'l applications and performs a few dbench runs.
The apps are killed in lifo order to see if the page aging works.
Afterwards, the find is performed again to see if any of the slabs are
still cached.
vmstat is running through the entire test, and /proc/[mem,slab]info are
saved very occasionally.
I ran the test on 2.5.27-rmap and 2.5.27-rmap-slablru to test
pte_chain reclaim and to see if the slablru patch causes measurable
slowdowns due to more LRU list traffic. It apparently doesn't:
Time to completion:
2.5.27: 203 sec
2.5.27-rmap: 205 sec
2.5.27-rmap-slablru: 205 sec
Swapouts during test:
2.5.27: 30092 kB
2.5.27-rmap: 43520 kB
2.5.27-rmap-slablru: 40948 kB
Swapins during test:
2.5.27: 13364 kB
2.5.27-rmap: 8616 kB
2.5.27-rmap-slablru: 8452 kB
Slab reclaim looks sane for the slablru kernel throughout the test. In
particular, here's the pte_chain pool entries through the test from
/proc/slabinfo:
pte_chain 20061 21294 8 60 63 1
pte_chain 20061 21294 8 60 63 1
pte_chain 20822 24336 8 65 72 1
pte_chain 21563 24336 8 65 72 1
pte_chain 19921 23660 8 70 70 1
pte_chain 18501 23660 8 63 70 1
pte_chain 18483 22984 8 63 68 1
Not very dramatic in this example since this was a pretty mild load, but
it does seem to work.
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 prev parent reply other threads:[~2002-07-22 7:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-21 11:24 Craig Kulesa
2002-07-21 21:31 ` William Lee Irwin III
2002-07-22 7:08 ` Craig Kulesa [this message]
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.0207212340530.13407-100000@loke.as.arizona.edu \
--to=ckulesa@as.arizona.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wli@holomorphy.com \
/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