LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Ferenc Wagner <wferi@niif.hu>
Cc: David Chinner <dgc@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: inode leak in 2.6.24?
Date: Wed, 20 Feb 2008 12:04:06 +1100	[thread overview]
Message-ID: <20080220010405.GF155407@sgi.com> (raw)
In-Reply-To: <87skzoanq3.fsf@szonett.ki.iif.hu>

On Tue, Feb 19, 2008 at 05:57:08PM +0100, Ferenc Wagner wrote:
> David Chinner <dgc@sgi.com> writes:
> > On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
> So, I loaded the same kernel on a different machine, but that seems to
> exhibit a very similar behaviour.  The machine is absolutely idle,
> nobody logged in during this period, though an updatedb ran during
> this period.  However, the increase seems steady, not correlated to
> cron.daily.
> 
> The contents of /proc/sys/fs/inode-nr after reboot was:
> 4421	95
> 
> and now, 13h35m later it's:
> 146182	0
> 
> Find the two slabinfo outputs attached.

Content-Description: slabinfo output immediately after reboot
> xfs_inode            791    800    384   10    1 : tunables   54   27    8 : slabdata     80     80      0
> xfs_vnode            790    790    384   10    1 : tunables   54   27    8 : slabdata     79     79      0
> dentry              5133   5133    132   29    1 : tunables  120   60    8 : slabdata    177    177      0

Content-Description: slabinfo output 13h35m after reboot
> xfs_inode         142548 142550    384   10    1 : tunables   54   27    8 : slabdata  14255  14255      0
> xfs_vnode         142548 142550    384   10    1 : tunables   54   27    8 : slabdata  14255  14255      0
> dentry            148003 148074    132   29    1 : tunables  120   60    8 : slabdata   5106   5106      0

> The xfs_inode, xfs_vnode and dentry lines show significant increase.
> The machine indeed uses XFS as its root filesystem.  Hope this gives
> enough clues to narrow down the problem.  I can try other kernels if
> needed.

The xfs inodes are clearly pinned by the dentry cache, so the issue
is dentries, not inodes. What's causing dentries not to be
reclaimed?  I can't see anything that cold pin them (e.g. no filp's
that would indicate open files being responsible), so my initial
thoughts are that memory reclaim may have changed behaviour.

I guess the first thing to find out is whether memory pressure
results in freeing the dentries. To simulate memory pressure causing
slab cache reclaim, can you run:

# echo 2 > /proc/sys/vm/drop_caches

and see if the number of dentries and inodes drops. If the number
goes down significantly, then we aren't leaking dentries and there's
been a change in memoy reclaim behaviour. If it stays the same, then
we probably are leaking dentries....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  reply	other threads:[~2008-02-20  1:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-15 23:18 Ferenc Wagner
2008-02-18 21:53 ` David Chinner
2008-02-19  0:50   ` Ferenc Wagner
2008-02-19 16:57   ` Ferenc Wagner
2008-02-20  1:04     ` David Chinner [this message]
2008-02-20 14:36       ` Ferenc Wagner
2008-02-20 21:15         ` David Chinner
2008-03-01 15:25           ` Ferenc Wagner

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=20080220010405.GF155407@sgi.com \
    --to=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wferi@niif.hu \
    --subject='Re: inode leak in 2.6.24?' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).