[lkml]   [2010]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git pull] vfs part 3 (write_inode mess)
    On Mon, 2010-03-08 at 15:22 -0500, Steve Dickson wrote: 
    > On 03/05/2010 12:40 PM, Al Viro wrote:
    > > On Fri, Mar 05, 2010 at 03:48:23PM +0000, Al Viro wrote:
    > >> I'm going to push the next VFS pile in about half an hour and get to the
    > >> write_inode situation. I'm not sure what's the best course here. Note
    > >> that since you've pulled it, you also have conflicts with what's in the
    > >> mainline. I can do *another* backmerge (already had one due to gfs2 trivial
    > >> conflicts) and push the result. Which will suck, since XFS conflicts
    > >> are not entirely trivial and we'll get a really ugly merge node, with
    > >> conflict resolution both hidden and not quite obvious.
    > >
    > > OK, a backmerge it is. Linus, could you please pull
    > > write_inode
    > > or suggest a saner way to do that?
    > >
    > > I've done backmerges of two points in mainline (trees that got merged
    > > into mainline, actually) that created conflicts. So at that point it's
    > > (a) descendent of what's been pulled into NFS tree and (b) merges clean
    > > with mainline. All for two patches (at commit 716c28c..) ;-/
    > >
    > > It's independent from the previous VFS pull; there's more stuff, hopefully
    > > for later today, but the worst of the mess should be gone with that one.
    > Has there been any kind of testing that show this approach does indeed
    > improve performance? Any hardcore number?
    > Just curious....

    The main improvement I'm seeing is in number of over the wire COMMIT
    operations. With a standard 2.6.32/33 kernel without these changes, if I
    do something like

    iozone -t 8 -s 512m -r 128k -i0 -i1

    on my old 2GB test machines then I end up seeing 1 COMMIT going on the
    wire for every 4 WRITE requests. IOW: I force the server to fsync for
    every 4x256K I send it.

    With the new code, I'm seeing 1 COMMIT being sent for every 50 WRITE

    Writeback throughput is slightly, but not hugely improved on my test
    rig. Furthermore, the maximum number of unstable writes recorded
    in /proc/meminfo doesn't appear to change much. All this points to the
    fact that most of those extra COMMIT calls were going out for just 1 or
    2 writes, probably as a result of looping in balance_dirty_pages() while
    the server was busy dealing with the first COMMIT.

    It is definitely worth getting rid of that extra spam to the server,
    though. Furthermore, I believe that others reported larger performance
    improvements when the number of commits went down.


     \ /
      Last update: 2010-03-11 00:11    [W:0.022 / U:0.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site