Re: 2.6.16-mm1 leaks in dvb playback

[Andrew Morton <akpm@osdl.org>]

adrian <adrian@smop.co.uk> wrote:
>
> On Mon, Mar 27, 2006 at 17:23:56 -0800 (-0800), Andrew Morton wrote:
> > 
> > Do you mean that the problem has been present in -mm kernels since the
> > 2.6.14/15 timeframe, and not in mainline?
> 
> Correct.
> 
> > Strange.  Are you sure that they really leak?  Doing
> > 
> > 	echo 3 > /proc/sys/vm/drop_caches
> > 
> > doesn't make them go away?
> 
> dentry_cache drops a little bit, but the vast majority stays.
> sock_inode_cache I didn't notice drop.  If I don't reboot every
> 15/20mins the machine suddenly starts thrashing like mad and then
> effectively locks up :-(
> 
> Last night I tried reverting the dvb-core ringbuffer part of -mm1 and
> that didn't seem to help at all.  
> 
> I've just tried 2.6.16 with just the origin.patch from -mm1 and that
> has the same leak in it.   So it looks like I should have spotted this
> earlier before it was pushed into 2.6.16+  Just double checked and
> in 2.5.16 sock_inode_cache isn't even on the slabtop screen.
>
> I suppose that leads to a new question - what's the easiest way to
> start to break down origin.patch and do you know of any likely
> culprits?  I see Andi Kleen has seen dentry_cache leaking on x86_64
> (this machine is x86(_32) uni processor. 
> 

It's unlikely that the sock_inode_cache leak is related to the dcache leak,
but we won't know until we know...

As for breaking down origin.patch: that's all in Linus's tree now, so
git-bisect is the way to do that.

As for a culprit: don't know, sorry.  I'd be surprised if there were _any_
patches which were in 2.6.14-mmX all the way through to 2.6.16-rc6-mmx and
which suddenly got merged into 2.6.16-git.  Maybe someone was sitting on
something for that long in one of the git trees, but I'd be surprised.