[lkml]   [2011]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] get_write_access()/deny_write_access() without inode->i_lock
    On Mon, Jun 20, 2011 at 08:55:38AM -0700, Linus Torvalds wrote:
    > On Sun, Jun 19, 2011 at 4:51 PM, Al Viro <> wrote:
    > > ? ? ? ?I'm seriously tempted to throw away i_lock uses in
    > > {get,deny}_write_access(), as in the patch below. ?The question is, how
    > > badly will it suck on various architectures? ?I'd expect it to be not
    > > worse than the current version, but...
    > It might be worse, because doing a read-before-write can turn a single
    > cache operation ("get for write") into multiple cache operations ("get
    > for read" followed by "make exclusive").

    Er... The current mainline does atomic_read() followed by atomic_inc(),
    so we get the same thing (plus the spin_lock()/spin_unlock()), don't we?

    > We had that exact issue with some other users of the "read + cmpxchg" model.
    > The way we fixed it before was to simply omit the read, and turn that
    > into a "guess".
    > In other words, I'd suggest you get rid of the "atomic_read()"
    > entirely, and just assume that the write counter was zero to begin
    > with. Even if that is a wrong assumption (and it probably isn't all
    > that wrong), it can actually be more efficient to essentiall go
    > through the loop twice: the first time yoou use the cmpxchg as just an
    > odd way to do a read. It basically bcomes a read-with-write-intent,
    > and solves the cacheline issue.

    For get_write_access() it's probably the right assumption for everything but
    /dev/tty*; for deny_write_access() it's not - a lot of binaries are run by
    more than one process...

    FWIW, I wonder what will the things look like on ll/sc architectures;
    maybe it's really better to turn that into atomic_inc_unless_negative()
    and let the architectures override the default...

     \ /
      Last update: 2011-06-20 18:17    [W:0.021 / U:63.872 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site