mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Wang You <wangyoua@uniontech.com>, axboe@kernel.dk
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	hch@lst.de, jaegeuk@kernel.org, fio@vger.kernel.org,
	ming.lei@redhat.com, wangxiaohua@uniontech.com
Subject: Re: [PATCH v2 2/2] block/mq-deadline: Prioritize first request
Date: Fri, 22 Jul 2022 10:47:12 -0700	[thread overview]
Message-ID: <f798c875-0bb9-add7-d7a3-4ac2a76e85d9@acm.org> (raw)
In-Reply-To: <20220722095120.371212-3-wangyoua@uniontech.com>

On 7/22/22 02:51, Wang You wrote:
> The test hardware is:
> Kunpeng-920, HW-SAS3508+(MG04ACA400N * 2), RAID0.

What is MG04ACA400N? The test results suggest that it is an SSD but this 
is something that should be mentioned explicitly.

> - The test hardware is:
> Hygon C86, MG04ACA400N

What is MG04ACA400N?

> The test command is:
> fio -ioengine=psync -lockmem=1G -buffered=0 -time_based=1 -direct=1 -iodepth=1
> -thread -bs=512B -size=110g -numjobs=32 -runtime=300 -group_reporting
> -name=read -filename=/dev/sdc -ioscheduler=mq-deadline -rw=read[,write,rw]
> 
> The following is the test data:
> origin/master:
> read iops: 15463	write iops: 5949	rw iops: 574,576
> 
> nr_sched_batch = 1:
> read iops: 15082	write iops: 6283	rw iops: 783,786
> 
> nr_sched_batch = 1, use deadline_head_request:
> read iops: 15368	write iops: 6575	rw iops: 907,906

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?

Thanks,

Bart.

  reply	other threads:[~2022-07-22 17:47 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 [this message]
2022-07-23 10:59     ` Wang You
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=f798c875-0bb9-add7-d7a3-4ac2a76e85d9@acm.org \
    --to=bvanassche@acm.org \
    --cc=axboe@kernel.dk \
    --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 \
    --cc=wangyoua@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

all inboxes | Powered by JetHome®