From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: bharata@in.ibm.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: dcache leak in 2.6.16-git8 II
Date: Thu, 30 Mar 2006 00:26:58 +0200 [thread overview]
Message-ID: <200603300026.59131.ak@suse.de> (raw)
In-Reply-To: <20060327190027.24498e3a.akpm@osdl.org>
On Tuesday 28 March 2006 05:00, Andrew Morton wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> > On Monday 27 March 2006 13:48, Bharata B Rao wrote:
> > > On Mon, Mar 27, 2006 at 07:50:20AM +0200, Andi Kleen wrote:
> > > >
> > > > A 2GB x86-64 desktop system here is currently swapping itself to death after
> > > > a few days uptime.
> > > >
> > > > Some investigation shows this:
> > > >
> > > > inode_cache 1287 1337 568 7 1 : tunables 54 27 8 : slabdata 191 191 0
> > > > dentry_cache 1867436 1867643 208 19 1 : tunables 120 60 8 : slabdata 98297 98297 0
> > > >
> > >
> > > Would it be possible to try out this experimental patch which
> > > gets some stats from the dentry cache ?
> >
> > It should be trivial to reproduce by other people. Biggest workload
> > is kernel compiles and quilt.
> >
> > After a few hours with -git12 it's already at
> >
> > dentry_cache 947013 952014 208 19 1 : tunables 120 60 8 : slabdata 50100 50106 480
> >
> > and starting to go into swap.
> >
> > I can't imagine I'm the only one seeing this?
> >
> > I have a few x86-64 patches applied too, but they don't change anything
> > in this area.
>
> I don't think I can reproduce this on x86 uniproc. (avtab_node_cache
> is a different story - maintainers separately pinged).
I got another OOM from this with -git13. Unfortunately it seems to take a few days at least
to trigger.
dentry_cache 999168 1024594 208 19 1 : tunables 120 60 8 : slabdata 53926 53926 0 : shrinker stat 18522624 8871000
Hrm interesting is this one:
sock_inode_cache 996784 996805 704 5 1 : tunables 54 27 8 : slabdata 199361 199361 0
Most of the leaked dentries seem to be sockets. I didn't notice this earlier.
This was with the debugging patches applied btw.
So maybe we have a socket leak?
I still got a copy of the /proc in case anybody wants more information.
-Andi
meminfo debugging was
r_dentries/page nr_pages nr_inuse
0 0 0
1 139 139
2 115 230
3 99 297
4 103 412
5 84 419
6 80 480
7 75 519
8 65 520
9 52 466
10 58 580
11 55 605
12 73 868
13 124 1610
14 184 2576
15 313 4685
16 518 8288
17 1338 22744
18 4591 82633
19 45843 870758
20 0 0
21 0 0
22 0 0
23 0 0
24 0 0
25 0 0
26 0 0
27 0 0
28 0 0
29 0 0
Total: 53909 998829
dcache lru: total 232 inuse 1
next parent reply other threads:[~2006-03-29 22:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200603270750.28174.ak@suse.de>
[not found] ` <200603271822.28043.ak@suse.de>
[not found] ` <20060327190027.24498e3a.akpm@osdl.org>
2006-03-29 22:26 ` Andi Kleen [this message]
2006-03-29 22:50 ` dcache leak in 2.6.16-git8 II Andrew Morton
2006-03-29 22:53 ` Andi Kleen
2006-03-30 6:41 ` Balbir Singh
2006-03-30 9:50 ` Al Viro
2006-03-30 10:12 ` Al Viro
2006-03-30 10:36 ` Al Viro
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=200603300026.59131.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=bharata@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).