lkml.org 
[lkml]   [2005]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.14 kswapd eating too much CPU

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

    ?





    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-11-28 14:49    [W:0.028 / U:1.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site