Re: Monster file_lock_cache entry in /proc/slabinfo

Re: Monster file_lock_cache entry in /proc/slabinfo

[Andrew Morton]

"James H. Cloos Jr." <cloos@jhcloos.com> wrote:
>
> My notebook has been slowing down the longer it is up for several
> kernel versions.  Disk i/o seems to be the chokepoint.
> 
> I grabbed slabinfo before today's reboot.  The box had been up for 10
> days -- it starts to become painful after about five or six days.
> 
> The file_lock_cache entry seemed rather engrossed:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test5/2.6.0-test5-mm2/broken-out/file-locking-leak-fix.patch

Monster file_lock_cache entry in /proc/slabinfo

[James H. Cloos Jr.]

My notebook has been slowing down the longer it is up for several
kernel versions.  Disk i/o seems to be the chokepoint.

I grabbed slabinfo before today's reboot.  The box had been up for 10
days -- it starts to become painful after about five or six days.

The file_lock_cache entry seemed rather engrossed:

file_lock_cache   2339148 2339148     92   42    1 : \
tunables  120   60    0 : \
slabdata  55694  55694      0

55694 slabs containing 2339148 objs?

The biggest user of file locking would be incoming email.  uucico(8)
polls a remote server, injects the mail to postfix(8) via postfix's
/usr/sbin/sendmail.  Postfix delivers via procmail(1), which pipes
the mail through SpamAssassin and then delivers to foo/. style 
destinations.  The recipies all start with :0:, so a local lock
file is used in each directory.  The destination filesystem is
ext3 with htree (and the default journal style).

I presume something is calling locks_alloc_lock but then failing to
also call locks_free_lock, but /proc/locks only ever shows around 6 or
so entries....

Any suggestions on debugging this?

-JimC

Re: Monster file_lock_cache entry in /proc/slabinfo

[Chris Wright]

* James H. Cloos Jr. (cloos@jhcloos.com) wrote:
> 
> The file_lock_cache entry seemed rather engrossed:

Is this a recent 2.6.0-test?  Matthew Wilcox posted a patch for this:

http://ftp.linux.org.uk/pub/linux/willy/patches/flock-memleak.diff

You might give that a try.
thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Monster file_lock_cache entry in /proc/slabinfo

[James H. Cloos Jr.]

Is file_lock_cache only a recent issue, then?  The slowdown has been
going on for at least the last 20 or so release tags.

If this is new I probably need to look at htree or the possibility
that it is a disk firmware issue (it being a laptop and all)....

Thanks for both replies.

-JimC

Re: Monster file_lock_cache entry in /proc/slabinfo

[Martin Josefsson]

On Mon, 2003-09-15 at 22:25, Andrew Morton wrote:

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test5/2.6.0-test5-mm2/broken-out/file-locking-leak-fix.patch

Andrew, please replace that patch with

http://ftp.linux.org.uk/pub/linux/willy/patches/flock-memleak2.diff

Which is the second version of this bugfixing, it fixes this problem and
another leak. I can't reproduce any more leaks with this patch ontop of
-mm1.

-- 
/Martin

Re: Monster file_lock_cache entry in /proc/slabinfo

[Martin Josefsson]

On Mon, 2003-09-15 at 22:56, James H. Cloos Jr. wrote:
> Is file_lock_cache only a recent issue, then?  The slowdown has been
> going on for at least the last 20 or so release tags.
> 
> If this is new I probably need to look at htree or the possibility
> that it is a disk firmware issue (it being a laptop and all)....

This has been with us for some time, it just got fixed :)

-- 
/Martin

Re: Monster file_lock_cache entry in /proc/slabinfo

[Chris Wright]

* James H. Cloos Jr. (cloos@jhcloos.com) wrote:
> Is file_lock_cache only a recent issue, then?  The slowdown has been
> going on for at least the last 20 or so release tags.

Comparing the patch lines to the repo history in bk, this looks like
it's been around since 2.5.39 or so...I suspect this patch is all you
need.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net