diff options
author | Christoph Hellwig <hch@lst.de> | 2023-05-03 09:06:13 +0200 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2023-06-19 13:59:23 +0200 |
commit | da023618076a13c35bcde1a49a87b7da64761f1d (patch) | |
tree | dcb8b9dd56e5b841e50a04b03b1d8088b79cf2a1 /fs/btrfs/super.c | |
parent | adbe7e388e4239d9c1754d475aea791136927137 (diff) | |
download | linux-da023618076a13c35bcde1a49a87b7da64761f1d.tar.gz linux-da023618076a13c35bcde1a49a87b7da64761f1d.tar.bz2 linux-da023618076a13c35bcde1a49a87b7da64761f1d.zip |
btrfs: submit IO synchronously for fast checksum implementations
Most modern hardware supports very fast accelerated crc32c calculation.
If that is supported the CPU overhead of the checksum calculation is
very limited, and offloading the calculation to special worker threads
has a lot of overhead for no gain.
E.g. on an Intel Optane device is actually very much slows down even
1M buffered writes with fio:
Unpatched:
write: IOPS=3316, BW=3316MiB/s (3477MB/s)(200GiB/61757msec); 0 zone resets
With synchronous CRCs:
write: IOPS=4882, BW=4882MiB/s (5119MB/s)(200GiB/41948msec); 0 zone resets
With a lot of variation during the unpatched run going down as low as
1100MB/s, while the synchronous CRC version has about the same peak write
speed but much lower dips, and fewer kworkers churning around.
Both tests had fio saturated at 100% CPU.
(thanks to Jens Axboe via Chris Mason for the benchmarking)
Reviewed-by: Chris Mason <clm@fb.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/super.c')
0 files changed, 0 insertions, 0 deletions