This patchset improve the latency of the space reservation when doing the delalloc inode flush. As we know, the current code would wait for the completion all the ordered extents in the filesystem. It was unnecessary, we can finish the wait and try to do reservation once again earlier if we get enough free space. It can reduce the wait time and make the perfermance up. We did the buffered write test by the sysbench on my box, the following is the result. Memory: 2GB CPU: 2Cores * 1CPU Partition: 20GB(SSD) w/ w/o rndwr-512KB-1Thread-2GB 120.38MB/s 110.08MB/s rndwr-512KB-8Threads-2GB 119.43MB/s 110.96MB/s seqwr-512KB-1Thread-2GB 99.676MB/s 98.53MB/s seqwr-512KB-8Threads-2GB 111.79MB/s 99.176MB/s rndwr-128KB-1Thread-2GB 139.23MB/s 95.864MB/s rndwr-128KB-8Threads-2GB 126.16MB/s 96.686MB/s seqwr-128KB-1Thread-2GB 100.24MB/s 100.95.MB/s seqwr-128KB-8Threads-2GB 126.51MB/s 100.26MB/s rndwr: random write test seqwr: sequential write test 512KB,128KB: the size of each request 1Thread, 8Threads: the number of the test threads 2GB: The total file size Miao Xie (7): Btrfs: remove unnecessary initialization and memory barrior in shrink_delalloc() Btrfs: wait for the ordered extent only when we want Btrfs: pick up the code for the item number calculation in flush_space() Btrfs: fix the confusion between delalloc bytes and metadata bytes Btrfs: don't wait for all the async delalloc when shrinking delalloc Btrfs: don't wait for the completion of all the ordered extents Btrfs: rename btrfs_start_all_delalloc_inodes fs/btrfs/ctree.h | 3 +-- fs/btrfs/dev-replace.c | 6 ++--- fs/btrfs/extent-tree.c | 62 ++++++++++++++++++++++++++++++++++--------------- fs/btrfs/inode.c | 3 +-- fs/btrfs/ioctl.c | 2 +- fs/btrfs/ordered-data.c | 22 ++++++++++++++---- fs/btrfs/ordered-data.h | 4 ++-- fs/btrfs/relocation.c | 4 ++-- fs/btrfs/super.c | 2 +- fs/btrfs/transaction.c | 4 ++-- 10 files changed, 73 insertions(+), 39 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
