Re: 2.6.14 kswapd eating too much CPU

From: Jan Kasprzak
Date: Mon Nov 28 2005 - 08:16:36 EST


Andrew Morton wrote:
: Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:
: >
: > It does seem to scan SLABs intensively:
: >
: It might be worth trying the below. Mainly for the debugging check.
:
I have compiled a new kernel - 2.6.15-rc2 with the patch you
recommended and with the slab statistics patch Marcelo mentioned.
I have add the oprofile support, but apart from that it is the same
kernel. It seems that the kswapd system time peaks has disappeared,
or at least they are much lower - kswapd0 has eaten ~3 minutes from
11 hours of uptime (in one of my previous mails I found that it used
to be 117 minutes after ~10 hours of uptime). On my MRTG graphs
at http://www.linux.cz/stats/mrtg-rrd/cpu.html some _small_ peaks
can be seen at 15 minutes after every odd-numbered hour. I have booted
this kernel around 2am local time.

I have no unusual error messages in dmesg output, so this must
be this part of the patch:

: + /*
: + * Avoid risking looping forever due to too large nr value:
: + * never try to free more than twice the estimate number of
: + * freeable entries.
: + */
: + if (shrinker->nr > max_pass * 2)
: + shrinker->nr = max_pass * 2;

The shrinker statistics displayed in /proc/slabinfo are
# egrep '^(inode|dentry)_cache' /proc/slabinfo
inode_cache 1338 1380 600 6 1 : tunables 54 27 8 : slabdata 230 230 0 : shrinker stat 261765504 16831100
dentry_cache 40195 49130 224 17 1 : tunables 120 60 8 : slabdata 2890 2890 204 : shrinker stat 57946368 28877600

-Yenya

--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
> Specs are a basis for _talking_about_ things. But they are _not_ a basis <
> for implementing software. --Linus Torvalds <
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/