From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH v2] block: remove plug based merging
Date: Thu, 14 Oct 2021 11:29:54 +0800 [thread overview]
Message-ID: <YWekMiP1+dqlwEYd@T590> (raw)
In-Reply-To: <fb4e2033-24fb-cd47-5e8d-557c8431097f@kernel.dk>
Hello Jens,
On Wed, Oct 13, 2021 at 02:00:35PM -0600, Jens Axboe wrote:
> It's expensive to browse the whole plug list for merge opportunities at
> the IOPS rates that modern storage can do. For sequential IO, the one-hit
> cached merge should suffice on fast drives, and for rotational storage the
> IO scheduler will do a more exhaustive lookup based merge anyway.
>
> Just remove the plug based O(N) traversal merging.
This way looks too aggressive, is there any performance data with the plug
merge which is supposed to be fast since it is totally lockless?
Maybe we can simply check if the incoming bio can be merged to the last or 1st
request in the plug list?
>
> With that, there's really no difference between the two plug cases that
> we have. Unify them.
IMO, there are differences between the two:
1) blk_attempt_plug_merge() is lockless, and no request allocation is
involved for merging incoming sequential bio.
2) after plug merge is killed, the merge is delayed until request is
allocated & added to plug list: a) for elevator, the merge requires lock
when running blk_mq_sched_insert_requests() b) for none, there isn't
merge any more, and small IO is always sent to driver because blk_mq_insert_requests
doesn't merge requests.
Thanks,
Ming
prev parent reply other threads:[~2021-10-14 3:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 20:00 [PATCH v2] block: remove plug based merging Jens Axboe
2021-10-14 3:29 ` Ming Lei [this message]
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=YWekMiP1+dqlwEYd@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
/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