Re: 2.6.14 kswapd eating too much CPU

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Mon, Nov 28, 2005 at 02:16:48PM +0100, Jan Kasprzak wrote:
> Andrew Morton wrote:
> : Marcelo Tosatti <marcelo.tosatti@cyclades.com> 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;

Yep, great.

> 
> 	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

Interesting, the success/attempt reclaim ratio for the dentry cache is
about 1/2 (pretty good), while the inode cache ratio is 1/15 (not so good).

I wonder why prune_icache() does not move inodes with positive i_count
to inode_inuse list, letting iput() take care of moving to unused
once the count reaches zero.

                inode = list_entry(inode_unused.prev, struct inode, i_list);
                if (inode->i_state || atomic_read(&inode->i_count)) {
                        list_move(&inode->i_list, &inode_unused);
                        continue;
                }

Couldnt it be 
			list_move(&inode->i_list, &inode_inuse);

?