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

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Apr 17, 2009 at 11:44:31AM -0700, Matthew Wilcox wrote:
> 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.

It's only lockd that actually runs *entirely* under the BKL--and lockd
obviously has a close relationship with the locks.c code, so there's a
fear of (unknown) dependencies there.

Also, more concretely (and what you probably had in mind), there are a
couple places where the nfs client or server explicitly take the bkl
just to traverse the lock list.

> 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.

I've been saying for a while I'd look into this, but keep getting
distracted, apologies.... I'll see if I can at least deal with the
obvious nfs client/server lock list traversals this time around.

--b.