[lkml]   [2008]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority
    On Thu, 2 Oct 2008 21:50:26 -0700
    Andrew Morton <> wrote:

    > >
    > > I also notice it's part of "file_update_time". Do we really need to
    > > go all the way down to this level of synchronicity for that?
    > Well, we've tossed that around many times but never implemented it.
    > Once you get into the details it gets a bit nasty. Need to keep the
    > dirtiness state in the VFS (or fs) inode, and going backwards from a
    > plain old buffer_head at commit time isn't possible. We usually
    > tempfixed the problem by adding increasingly fancy ways of not doing
    > the atime update at all.

    given that this is the write path, I was assuming this was mtime rather
    than atime; doesn't change your answer though.
    > Of course, fixing this running-vs-committing contention point would
    > fix a lot more things than just atime updates.

    yes clearly. It's waaay above my paygrade to hack on though; JBD is one
    of those places in the kernel that scare me for doing fundamental
    changes ;-(

    > > (I also randomly wonder if we, in the write path, dirty the inode
    > > twice, once for size once for item, and if we then also reserve two
    > > slots in the journal for that.....
    > That shouldn't be the case - once we have write access to the buffer
    > it remains freely modifiable for the rest of the transaction period.
    > I think.

    I hope you're right otherwise we'd always hit this; once for the size
    change, then block for the mtime. That would thoroughly suck; so much
    so that you just must be right.

    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,

     \ /
      Last update: 2008-10-03 07:03    [W:0.030 / U:2.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site