From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Curt Wohlgemuth <curtw@google.com>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
Subject: [PATCH 0/6] Cleanup and improve sync (v3)
Date: Fri, 7 Oct 2011 22:40:49 +0200 [thread overview]
Message-ID: <1318020055-4450-1-git-send-email-jack@suse.cz> (raw)
Hello,
this is a third iteration of my series improving handling of sync syscall.
Since previous submission I have changed ordering of patches and split some
patches as Christoph suggested.
I have run three tests below to verify performance impact of the patch series.
Each test has been run with 1, 2, and 4 filesystems mounted; test with 2
filesystems was run with each filesystem on a different disk, test with 4
filesystems had 2 filesystems on the first disk and 2 filesystems on the second
disk.
Test 1: Run 200 times sync with filesystem mounted to verify overhead of
sync when there are no data to write.
Test 2: For each filesystem run a process creating 40 KB files, sleep
for 3 seconds, run sync.
Test 3: For each filesystem run a process creating 20 GB file, sleep for
5 seconds, run sync.
I have performed 10 runs of each test for xfs, ext3, ext4, and btrfs
filesystems.
Results of test 1
-----------------
Numbers are time it took 200 syncs to complete.
Character in braces is + if the time increased with 2*STDDEV reliability,
- if it decreased with 2*STDDEV reliability, 0 otherwise.
BASE PATCHED
FS AVG STDDEV AVG STDDEV
xfs, 1 disks 4.189300 0.051525 2.141300 0.063389 (-)
xfs, 2 disks 4.820600 0.019096 4.611400 0.066322 (-)
xfs, 4 disks 6.518300 1.440362 6.435700 0.510641 (0)
ext4, 1 disks 4.085000 0.011375 1.689500 0.001360 (-)
ext4, 2 disks 4.088100 0.006488 1.705000 0.026359 (-)
ext4, 4 disks 4.107300 0.011934 1.702900 0.001814 (-)
ext3, 1 disks 4.080200 0.009527 1.703400 0.030559 (-)
ext3, 2 disks 4.138300 0.143909 1.694000 0.001414 (-)
ext3, 4 disks 4.107200 0.002482 1.702900 0.007778 (-)
btrfs, 1 disks 11.214600 0.086619 8.737200 0.081076 (-)
btrfs, 2 disks 32.910000 0.162089 30.673400 0.538820 (-)
btrfs, 4 disks 67.987700 1.655654 67.247100 1.971887 (0)
So we see nice improvements almost all over the board.
Results of test 2
-----------------
Numbers are time it took sync to complete.
BASE PATCHED
FS AVG STDDEV AVG STDDEV
xfs, 1 disks 0.436000 0.012000 0.506000 0.014283 (+)
xfs, 2 disks 1.105000 0.055543 1.274000 0.244426 (0)
xfs, 4 disks 5.880000 2.997135 4.837000 3.875448 (0)
ext4, 1 disks 0.791000 0.055579 0.853000 0.042438 (0)
ext4, 2 disks 18.232000 13.505638 17.254000 2.000506 (0)
ext4, 4 disks 491.790000 218.565229 696.783000 234.933562 (0)
ext3, 1 disks 15.315000 2.065465 1.900000 0.184662 (-)
ext3, 2 disks 128.524000 18.090519 55.278000 1.530554 (-)
ext3, 4 disks 221.202000 30.090432 232.849000 68.745423 (0)
btrfs, 1 disks 0.452000 0.026000 0.494000 0.023749 (0)
btrfs, 2 disks 5.156000 4.530852 4.083000 1.560519 (0)
btrfs, 4 disks 31.154000 11.220828 36.987000 17.334126 (0)
Except for ext3 which got a nice boost here and XFS which seems to be a tad bit
slower, there are no changes that would stand out of the noise.
Results of test 3
-----------------
Numbers are time it took sync to complete.
BASE PATCHED
FS AVG STDDEV AVG STDDEV
xfs, 1 disks 12.083000 0.058660 10.898000 0.285475 (-)
xfs, 2 disks 20.182000 0.549614 14.977000 0.351114 (-)
xfs, 4 disks 35.814000 5.318310 28.452000 3.332281 (0)
ext4, 1 disks 32.956000 5.753789 20.865000 3.892098 (0)
ext4, 2 disks 34.922000 3.051966 27.411000 2.752978 (0)
ext4, 4 disks 44.508000 6.829004 28.360000 2.561437 (0)
ext3, 1 disks 23.475000 1.288885 17.116000 0.319631 (-)
ext3, 2 disks 43.508000 4.998647 41.547000 2.597976 (0)
ext3, 4 disks 92.130000 11.344117 79.362000 9.891208 (0)
btrfs, 1 disks 12.478000 0.394304 12.847000 0.171117 (0)
btrfs, 2 disks 15.030000 0.777817 18.014000 2.011418 (0)
btrfs, 4 disks 32.395000 4.248859 38.411000 3.179939 (0)
Here we see XFS and ext3 had some improvements, ext4 likely as well although
the results are relatively noisy.
Out of curiosity, I also tried removing syncfs(sb, 0) call from the sync
sequence altogether as Christoph suggested. In the test 1, results end up being
even better, tests 2 and 3 end up roughly the same, sometimes slightly better.
I also performed tests where we write some amount of data to the filesystem
and then call sync - there were no changes in sync times that would stand out
of the noise. So this might be a worthwhile simplification of sync...
Honza
next reply other threads:[~2011-10-07 20:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 20:40 Jan Kara [this message]
2011-10-07 20:40 ` [PATCH 1/6] vfs: Move noop_backing_dev_info check from sync into writeback Jan Kara
2011-10-20 9:48 ` Christoph Hellwig
2011-10-07 20:40 ` [PATCH 2/6] quota: Split dquot_quota_sync() to writeback and cache flushing part Jan Kara
2011-10-20 9:50 ` Christoph Hellwig
2011-10-07 20:40 ` [PATCH 3/6] quota: Move quota syncing to ->sync_fs method Jan Kara
2011-10-07 20:40 ` [PATCH 4/6] vfs: Reorder operations during sys_sync Jan Kara
2011-10-20 9:53 ` Christoph Hellwig
2011-10-20 23:57 ` Jan Kara
2011-10-07 20:40 ` [PATCH 5/6] vfs: Make sys_sync writeout also block device inodes Jan Kara
2011-10-20 9:54 ` Christoph Hellwig
2011-10-07 20:40 ` [PATCH 6/6] vfs: Avoid unnecessary WB_SYNC_NONE writeback during sys_sync and reorder sync passes Jan Kara
2011-10-20 9:57 ` Christoph Hellwig
2011-10-24 13:14 ` Jan Kara
2011-10-18 1:07 ` [PATCH 0/6] Cleanup and improve sync (v3) Jan Kara
2011-10-18 6:45 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1318020055-4450-1-git-send-email-jack@suse.cz \
--to=jack@suse.cz \
--cc=curtw@google.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).