Re: [PATCH -tip] remove the BKL: Replace BKL in mount/umount syscalls with a mutex

[Matthew Wilcox <willy@linux.intel.com>]

On Fri, Apr 17, 2009 at 11:03:31AM -0700, Linus Torvalds wrote:
> Hmm. It might also just be my fevered imagination. I'd like to say it was 
> Matthew Wilcox, but really, my mind is going.
> 
> Ahh. Bug google backs me up. As long as I have google, I can keep 
> Alzheimer's at bay: "Negative scalability by removal of lock_kernel()" 
> thread on lkml back in October 2000. After we had actually done the BKL 
> removal.
> 
> So we actually did apply it (in 2.4.0-test9, and then reverted it again 
> (in -test11, I think). Google for "file_lock_sem fs/locks.c" and see some 
> of the discussion. The end result was to go back to the BKL due to Apache 
> slowdowns.

That's some good ancient history ;-)  It probably would make sense to
use a mutex rather than the BKL these days now that we spin on mutexes
if the other process is running.  Plus, I don't think modern Apache uses
file locks any more.

There was another attempt to remove the BKL from locks.c by Dave Hansen
a few years later.  That one foundered on the proposed locking scheme
being unadulterated crap; I seem to remember pointing out that it was
gathering O(n^2) locks ...

> But I seem to remember a later patch (in the last year or two) from Willy 
> too. Google doesn't help me, so that's probably just my fevered mind. But 
> I'm cc'ing Willy anyway.

Fortunately, this patch wasn't the product of a fevered anything.  It
was in response to the performance regressions I introduced by
introducing the generic semaphores that were too fair.

It didn't deal with the really knotty problem which was the NFS server
still running under the BKL and relying on the BKL to prevent other
CPUs from messing with the list of locks.

Since the problem turned out to be the TTY layer and not the file
locking code, we just dropped the patch, but if we'd like to resurrect
it again, we need to talk to the NFS folks.  Probably Bruce Fields is
the appropriate sucker.