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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/