From: Jens Axboe <axboe@kernel.dk>
To: Song Liu <song@kernel.org>,
linux-block@vger.kernel.org, linux-raid@vger.kernel.org
Cc: stable@vger.kernel.org, Larkin Lowrey <llowrey@nuclearwinter.com>,
Wilson Jonathan <i400sjon@gmail.com>,
Roger Heflin <rogerheflin@gmail.com>
Subject: Re: [PATCH] block: check more requests for multiple_queues in blk_attempt_plug_merge
Date: Thu, 10 Mar 2022 15:15:35 -0700 [thread overview]
Message-ID: <9516f407-bb91-093b-739d-c32bda1b5d8d@kernel.dk> (raw)
In-Reply-To: <20220309064209.4169303-1-song@kernel.org>
On 3/8/22 11:42 PM, Song Liu wrote:
> RAID arrays check/repair operations benefit a lot from merging requests.
> If we only check the previous entry for merge attempt, many merge will be
> missed. As a result, significant regression is observed for RAID check
> and repair.
>
> Fix this by checking more than just the previous entry when
> plug->multiple_queues == true.
>
> This improves the check/repair speed of a 20-HDD raid6 from 19 MB/s to
> 103 MB/s.
Do the underlying disks not have an IO scheduler attached? Curious why
the merges aren't being done there, would be trivial when the list is
flushed out. Because if the perf difference is that big, then other
workloads would be suffering they are that sensitive to being within a
plug worth of IO.
Between your two approaches, I do greatly prefer the first one though.
--
Jens Axboe
next prev parent reply other threads:[~2022-03-10 22:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 6:42 [PATCH] block: check more requests for multiple_queues in blk_attempt_plug_merge Song Liu
2022-03-10 6:48 ` Christoph Hellwig
2022-03-10 7:23 ` Song Liu
2022-03-10 22:10 ` Song Liu
2022-03-10 22:12 ` Song Liu
2022-03-10 22:15 ` Jens Axboe [this message]
2022-03-10 22:37 ` Song Liu
2022-03-10 23:02 ` Jens Axboe
2022-03-10 23:33 ` Song Liu
2022-03-11 0:07 ` Jens Axboe
2022-03-11 0:31 ` Song Liu
2022-03-11 0:36 ` Jens Axboe
2022-03-11 0:38 ` Jens Axboe
2022-03-11 1:14 ` Ming Lei
2022-03-11 1:21 ` Jens Axboe
2022-03-11 1:32 ` Ming Lei
2022-03-11 1:35 ` Jens Axboe
2022-03-11 8:09 ` Wols Lists
2022-03-11 14:16 ` Jens Axboe
2022-03-11 16:59 ` Song Liu
2022-03-11 21:41 ` Paul Menzel
2022-03-11 22:40 ` Song Liu
2022-03-11 11:30 ` Wilson Jonathan
2022-03-11 15:58 ` Wols Lists
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=9516f407-bb91-093b-739d-c32bda1b5d8d@kernel.dk \
--to=axboe@kernel.dk \
--cc=i400sjon@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=llowrey@nuclearwinter.com \
--cc=rogerheflin@gmail.com \
--cc=song@kernel.org \
--cc=stable@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;
as well as URLs for NNTP newsgroup(s).