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


     \ /
      Last update: 2009-04-22 19:31    [W:2.832 / U:0.096 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site