lkml.org 
[lkml]   [2009]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH -tip] remove the BKL: Replace BKL in mount/umount syscalls with a mutex
From
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.


\
 
 \ /
  Last update: 2009-04-22 19:31    [from the cache]
©2003-2011 Jasper Spaans