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
"James H. Cloos Jr." <[email protected]> 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
* James H. Cloos Jr. ([email protected]) 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
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
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
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
* James H. Cloos Jr. ([email protected]) 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