| Message ID | 9222613d-d4d3-7cfb-2e96-1bfa3b5f2d7f@kernel.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] block: only check previous entry for plug merge attempt | expand |
On Thu, Oct 14, 2021 at 12:34:21PM -0600, Jens Axboe wrote: > diff --git a/block/blk-merge.c b/block/blk-merge.c > index f390a8753268..575080ad0617 100644 > --- a/block/blk-merge.c > +++ b/block/blk-merge.c Even though the code is self-documenting, the current description on top of this function is now outdated with this change. - * Determine whether @bio being queued on @q can be merged with a request - * on %current's plugged list. Returns %true if merge was successful, + * Determine whether @bio being queued on @q can be merged with the previous + * request on %current's plugged list. Returns %true if merge was successful, * otherwise %false. > @@ -1089,32 +1089,22 @@ bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio, > { > struct blk_plug *plug; > struct request *rq; > - struct list_head *plug_list; > > plug = blk_mq_plug(q, bio); > - if (!plug) > + if (!plug || list_empty(&plug->mq_list)) > return false; > Regards, Pankaj Raghav
Looks good module the needed comment update:
Reviewed-by: Christoph Hellwig <hch@lst.de>
On 10/15/21 8:18 AM, Pankaj Raghav wrote: > On Thu, Oct 14, 2021 at 12:34:21PM -0600, Jens Axboe wrote: >> diff --git a/block/blk-merge.c b/block/blk-merge.c >> index f390a8753268..575080ad0617 100644 >> --- a/block/blk-merge.c >> +++ b/block/blk-merge.c > > Even though the code is self-documenting, the current description on top > of this function is now outdated with this change. > > - * Determine whether @bio being queued on @q can be merged with a request > - * on %current's plugged list. Returns %true if merge was successful, > + * Determine whether @bio being queued on @q can be merged with the previous > + * request on %current's plugged list. Returns %true if merge was successful, > * otherwise %false. Fixed up, thanks.
diff --git a/block/blk-merge.c b/block/blk-merge.c index f390a8753268..575080ad0617 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -1089,32 +1089,22 @@ bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio, { struct blk_plug *plug; struct request *rq; - struct list_head *plug_list; plug = blk_mq_plug(q, bio); - if (!plug) + if (!plug || list_empty(&plug->mq_list)) return false; - plug_list = &plug->mq_list; - - list_for_each_entry_reverse(rq, plug_list, queuelist) { - if (rq->q == q && same_queue_rq) { - /* - * Only blk-mq multiple hardware queues case checks the - * rq in the same queue, there should be only one such - * rq in a queue - **/ - *same_queue_rq = rq; - } - - if (rq->q != q) - continue; - - if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == - BIO_MERGE_OK) - return true; + /* check the previously added entry for a quick merge attempt */ + rq = list_last_entry(&plug->mq_list, struct request, queuelist); + if (rq->q == q && same_queue_rq) { + /* + * Only blk-mq multiple hardware queues case checks the rq in + * the same queue, there should be only one such rq in a queue + */ + *same_queue_rq = rq; } - + if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == BIO_MERGE_OK) + return true; return false; }
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. Signed-off-by: Jens Axboe <axboe@kernel.dk> --- v3: retain merge list, but only check last addition.