[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slablru for 2.5.32-mm1
- To: Ed Tomlinson <tomlins@cam.org>
- Subject: Re: slablru for 2.5.32-mm1
- From: Andrew Morton <akpm@zip.com.au>
- Date: Sun, 01 Sep 2002 23:50:38 -0700
- CC: linux-mm@kvack.org
- Fake-Sender: owner-linux-mm@kvack.org
- Original-Recipient: rfc822;linux-mm-archive@humbolt.geo.uu.nl
- References: <200208261809.45568.tomlins@cam.org> <3D6AC0BB.FE65D5F7@zip.com.au> <200208281306.58776.tomlins@cam.org>
- Sender: Rik van Riel <riel@nl.linux.org>
hm. Doing a bit more testing...
mem=512m, then build the inode and dentry caches up a bit:
ext2_inode_cache: 20483KB 20483KB 100.0
buffer_head: 6083KB 6441KB 94.43
dentry_cache: 4885KB 4885KB 100.0
(using wli's bloatmeter, attached here).
Now,
dd if=/dev/zero of=foo bs=1M count=2000
ext2_inode_cache: 3789KB 8148KB 46.50
buffer_head: 6469KB 6503KB 99.47
size-512: 1450KB 1500KB 96.66
this took quite a long time to start dropping, and the machine
still has 27 megabytes in slab.
Which kinda surprises me, given my (probably wrong) description of the
algorithm. I'd have expected the caches to be pruned a lot faster and
further than this. Not that it's necessarily a bad thing, but maybe we
should be shrinking a little faster. What are your thoughts on this?
Also, I note that age_dcache_memory is being called for lots of
tiny little shrinkings:
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=1, gfp_mask=464) at dcache.c:585
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=2, gfp_mask=464) at dcache.c:585
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=4, gfp_mask=464) at dcache.c:585
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=12, gfp_mask=464) at dcache.c:585
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=21, gfp_mask=464) at dcache.c:585
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=42, gfp_mask=464) at dcache.c:585
Breakpoint 1, age_dcache_memory (cachep=0xc1911e48, entries=10, gfp_mask=464) at dcache.c:585
I'd suggest that we batch these up a bit: call the pruner less
frequently, but with larger request sizes, save a few cycles.
#!/bin/sh
while true
do
clear
grep -v '^slabinfo' /proc/slabinfo \
| bloatmon \
| sort -r -n +2 \
| head -22
sleep 5
done
#!/usr/bin/awk -f
BEGIN {
printf "%18s %8s %8s %8s\n", "cache", "active", "alloc", "%util";
}
{
if ($3 != 0.0) {
pct = 100.0 * $2 / $3;
frac = (10000.0 * $2 / $3) % 100;
} else {
pct = 100.0;
frac = 0.0;
}
active = ($2 * $4)/1024;
alloc = ($3 * $4)/1024;
if ((alloc - active) < 1.0) {
pct = 100.0;
frac = 0.0;
}
printf "%18s: %8dKB %8dKB %3d.%-2d\n", $1, active, alloc, pct, frac;
}