[lkml]   [2009]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/4] Convert epoll to a bitlock
    On Tue, 3 Feb 2009 15:37:40 -0700
    Jonathan Corbet <> wrote:

    > On Tue, 03 Feb 2009 16:22:02 -0600
    > Matt Mackall <> wrote:
    > > But that re-opens the question of what to do about poor Jon's quest.
    > >
    > > I got confused halfway through as he went from using a global fasync
    > > spinlock to a non-locked but atomic flag bit. Not sure why using a
    > > per-file or per-inode lock doesn't work for the fasync code.
    > No per-file lock because (1) there is resistance to growing struct
    > file, and (2) lockless algorithms are all the rage now. Additionally,
    > solving the fasync-atomicity problem with locks requires the use of a
    > mutex (or the BKL) rather than a spinlock. I suppose we could combine
    > a global f_flags lock with the set-FASYNC-in-fasync_helper() bits.
    > At this point Poor Jon sees a fork in the road as he contemplates the
    > future of his quest:
    > - Go with this patch set, perhaps with a bit of cleanup as suggested by
    > Andrew.
    > - Go back to the global lock.
    > - Go away, leave the BKL in place, and wait for somebody smarter to
    > attack the problem.

    Well. We _could_ whack part of this nut with my usual hammer: protect
    f_flags with file->f_dentry->d_inode->i_lock. IIRC there was some
    objection to that - performance?

    One problem here seems to be that we're trying to change multiple
    things at the same time. We can blame the BKL for that.

    Can we break the problem into manageable chunks? Your patchset did
    that, I guess. What were those chunks again? ;)

     \ /
      Last update: 2009-02-03 23:57    [W:0.029 / U:58.328 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site