lkml.org 
[lkml]   [2006]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dcache leak in 2.6.16-git8
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'd expect pretty much everything we have in there now was under test in
-mm for quite some time - any obvious leaks would have been noticed. I'd
be suspecting recent changes in perhaps audit or nfs, at a guess. Or
something weird.

Which filesystems are in use?
-
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: 2006-03-28 05:03    [W:0.100 / U:1.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site