diff options
author | Jens Axboe <axboe@kernel.dk> | 2021-10-14 07:24:07 -0600 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2021-10-18 06:17:35 -0600 |
commit | d38a9c04c0d5637a828269dccb9703d42d40d42b (patch) | |
tree | bce553d6c897b8154deab934ad3fb57337dbbc25 /usr | |
parent | 4c928904ff771a8e830773b71a080047365324a5 (diff) | |
download | linux-stable-d38a9c04c0d5637a828269dccb9703d42d40d42b.tar.gz linux-stable-d38a9c04c0d5637a828269dccb9703d42d40d42b.tar.bz2 linux-stable-d38a9c04c0d5637a828269dccb9703d42d40d42b.zip |
block: only check previous entry for plug merge attempt
Currently we scan the entire plug list, which is potentially very
expensive. In an IOPS bound workload, we can drive about 5.6M IOPS with
merging enabled, and profiling shows that the plug merge check is the
(by far) most expensive thing we're doing:
Overhead Command Shared Object Symbol
+ 20.89% io_uring [kernel.vmlinux] [k] blk_attempt_plug_merge
+ 4.98% io_uring [kernel.vmlinux] [k] io_submit_sqes
+ 4.78% io_uring [kernel.vmlinux] [k] blkdev_direct_IO
+ 4.61% io_uring [kernel.vmlinux] [k] blk_mq_submit_bio
Instead of browsing the whole list, just check the previously inserted
entry. That is enough for a naive merge check and will catch most cases,
and for devices that need full merging, the IO scheduler attached to
such devices will do that anyway. The plug merge is meant to be an
inexpensive check to avoid getting a request, but if we repeatedly
scan the list for every single insert, it is very much not a cheap
check.
With this patch, the workload instead runs at ~7.0M IOPS, providing
a 25% improvement. Disabling merging entirely yields another 5%
improvement.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions