Christoph Hello
I am testing 2.6.38 with AIM benchmark.
I compared 2.6.38 to 2.6.27 and I noticed that 2.6.27 is much better than 2.6.38 when
doing sync random writes test over an xfs regular file over native Linux partition on top common sata disk.
I git bisected the problem and I reached this SHA1:
commit 13e6d5cdde0e785aa943810f08b801cadd0935df
Author: Christoph Hellwig <[email protected]>
Date: Mon Aug 31 21:00:31 2009 -0300
xfs: merge fsync and O_SYNC handling
The guarantees for O_SYNC are exactly the same as the ones we need to
make for an fsync call (and given that Linux O_SYNC is O_DSYNC the
equivalent is fdadatasync, but we treat both the same in XFS), except
with a range data writeout. Jan Kara has started unifying these two
path for filesystems using the generic helpers, and I've started to
look at XFS.
...
The bellow two tests presents the how different performance is before and patch:
#test 16) bisect 11
------------------------------------------------------------------------------------------------------------
Test Test Elapsed Iteration Iteration Operation
Number Name Time (sec) Count Rate (loops/sec) Rate (ops/sec)
------------------------------------------------------------------------------------------------------------
1 sync_disk_rw 30.71 19 0.61869 1583.85 Sync Random Disk Writes (K)/second
------------------------------------------------------------------------------------------------------------
#test 17 ) bisect 12
------------------------------------------------------------------------------------------------------------
1 sync_disk_rw 69.05 1 0.01448 37.07 Sync Random Disk Writes (K)/second
------------------------------------------------------------------------------------------------------------
Regards
Raz Ben-Yehuda
On Tue, Apr 12, 2011 at 10:52:28AM +0300, raz ben yehuda wrote:
> Christoph Hello
> I am testing 2.6.38 with AIM benchmark.
> I compared 2.6.38 to 2.6.27 and I noticed that 2.6.27 is much better than 2.6.38 when
> doing sync random writes test over an xfs regular file over native Linux partition on top common sata disk.
As Dave already mentioned in your double post of this mail this is
because data now actually is forced out to disk in all cases,
while you previously hit a bug in the O_SYNC implementation.