From: Wang You <wangyoua@uniontech.com>
To: bvanassche@acm.org
Cc: axboe@kernel.dk, fio@vger.kernel.org, hch@lst.de,
jaegeuk@kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, ming.lei@redhat.com,
wangxiaohua@uniontech.com, wangyoua@uniontech.com
Subject: Re: [PATCH v2 2/2] block/mq-deadline: Prioritize first request
Date: Sat, 23 Jul 2022 18:59:09 +0800 [thread overview]
Message-ID: <20220723105909.440050-1-wangyoua@uniontech.com> (raw)
In-Reply-To: <f798c875-0bb9-add7-d7a3-4ac2a76e85d9@acm.org>
> What is MG04ACA400N?
It is a Toshiba 7200 RPM hard drive.
> The above results are low enough such that these could come from a hard
> disk. However, the test results are hard to interpret since the I/O
> pattern is neither perfectly sequential nor perfectly random (32
> sequential jobs). Please provide separate measurements for sequential
> and random I/O.
> The above results show that this patch makes reading from a hard disk
> slower. Isn't the primary use case of mq-deadline to make reading from
> hard disks faster? So why should these two patches be applied if these
> slow down reading from a hard disk?
The data of MG04ACA400N on the raid controller is obviously different from
the single disk, especially the reading data, I did not expect this situation,
the data on the raid controller made me mistakenly think that the same applies
to HDD.
I will re-analyze the impact of this patch on the HDD later, please ignore it
for now.
Also, can I ask? If using fio or other tools, how should testing be done to get
more accurate and convincing data? Such as the perfectly sequential and random I/O
performance you mentioned above (fio's multi-threaded test does result in neither
perfectly sequential nor perfectly random, but single thread dispatch is too slow,
and cannot play the merge and sorting ability of elv).
Thanks,
Wang.
next prev parent reply other threads:[~2022-07-23 10:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-22 9:51 [PATCH v2 0/2] Improve mq-deadline performance in HDD Wang You
2022-07-22 9:51 ` [PATCH v2 1/2] block: Introduce nr_sched_batch sys interface Wang You
2022-07-22 17:35 ` Bart Van Assche
2022-07-23 10:04 ` Wang You
2022-07-22 9:51 ` [PATCH v2 2/2] block/mq-deadline: Prioritize first request Wang You
2022-07-22 17:47 ` Bart Van Assche
2022-07-23 10:59 ` Wang You [this message]
2022-07-25 1:48 ` Bart Van Assche
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=20220723105909.440050-1-wangyoua@uniontech.com \
--to=wangyoua@uniontech.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=fio@vger.kernel.org \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=wangxiaohua@uniontech.com \
/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).