All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: "Liu, Sunny" <ping.liu@lenovonetapp.com>,
	Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	James Bottomley <james.bottomley@hansenpartnership.com>,
	Christoph Hellwig <hch@lst.de>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	Hans Holmberg <Hans.Holmberg@wdc.com>
Subject: Re: [RFC PATCH 0/2] blk-mq I/O scheduling fixes
Date: Thu, 19 Sep 2019 10:03:36 +0000	[thread overview]
Message-ID: <BYAPR04MB581634BD1F85CA9768AC780FE7890@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: BJXPR01MB02964BA1F5E67B7B6CB39EE7F4890@BJXPR01MB0296.CHNPR01.prod.partner.outlook.cn

On 2019/09/19 11:57, Liu, Sunny wrote:
> Hello Sir,
> 
> I have a question about the I/O scheduler in kernel 5.2.9
> 
> in the new kernel, which I/O scheduler should be used by legacy rotating
> drive? Such as sata HDD? During FIO testing with libaio, I had create
> multiple thread in the testing, and then found 512k and bigger sequent write
> had bad performance result. Even I had enable and use BFQ scheduler.
> 
> There has no sq scheduler anymore, only has none, mq-deadline, kyber and
> BFQ. Mq-deadline and kyber is for fast block device. Only the BFQ looks
> better performance, but it can't keep the good behavior during 512k or bigger
> 100% seq write.
> 
> Could you give me some advices what parameter should I change for multiple
> thread bigger file seq writing?

The default block IO scheduler for a single queue device (e.g. HDDs in most
cases, but beware of the HBA being used and how it exposes the disk) is
mq-deadline. For a multiqueue device (e.g. NVMe SSDs), the default elevator is none.

For your SATA SSD, which is a single queue device, the default elevator will be
mq-deadline. This elevator should give you very good performance. "none" will
probably also give you the same results though.

Performance on SSD highly depends on the SSD condition (the amount and pattern
of writes preceding the test). You may want to trim the entire device before
writing it to check the maximum  performance you can get out of it.

> 
> Thanks all of you.
> 
> BestRegards, SunnyLiu(刘萍) LenovoNetApp 北京市海淀区西北旺东路10号院2号楼L3-E1-01 
> L3-E1-01,Building No.2, Lenovo HQ West No.10 XiBeiWang East Rd., Haidian
> District, Beijing 100094, PRC Tel: +86 15910622368
> 
> -----Original Message----- From: linux-block-owner@vger.kernel.org
> <linux-block-owner@vger.kernel.org> On Behalf Of Hannes Reinecke Sent: 2019年9
> 月19日 17:46 To: Jens Axboe <axboe@kernel.dk> Cc: linux-scsi@vger.kernel.org;
> Martin K. Petersen <martin.petersen@oracle.com>; James Bottomley
> <james.bottomley@hansenpartnership.com>; Christoph Hellwig <hch@lst.de>;
> linux-block@vger.kernel.org; Hans Holmberg <hans.holmberg@wdc.com>; Damien Le
> Moal <damien.lemoal@wdc.com>; Hannes Reinecke <hare@suse.de> Subject: [RFC
> PATCH 0/2] blk-mq I/O scheduling fixes
> 
> Hi all,
> 
> Damien pointed out that there are some areas in the blk-mq I/O scheduling
> algorithm which have a distinct legacy feel to it, and prohibit multiqueue
> I/O schedulers from working properly. These two patches should clear up this
> situation, but as it's not quite clear what the original intention of the
> code was I'll be posting them as an RFC.
> 
> So as usual, comments and reviews are welcome.
> 
> Hannes Reinecke (2): blk-mq: fixup request re-insert in
> blk_mq_try_issue_list_directly() blk-mq: always call into the scheduler in
> blk_mq_make_request()
> 
> block/blk-mq.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
> 
> -- 2.16.4
> 
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2019-09-19 10:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19  9:45 [RFC PATCH 0/2] blk-mq I/O scheduling fixes Hannes Reinecke
2019-09-19  9:45 ` [PATCH 1/2] blk-mq: fixup request re-insert in blk_mq_try_issue_list_directly() Hannes Reinecke
2019-09-19 14:19   ` Ming Lei
2019-09-20  6:42     ` Hannes Reinecke
2019-09-19 14:52   ` Guoqing Jiang
2019-09-19  9:45 ` [PATCH 2/2] blk-mq: always call into the scheduler in blk_mq_make_request() Hannes Reinecke
2019-09-19 10:21   ` Damien Le Moal
2019-09-19 14:23     ` Ming Lei
2019-09-19 15:48       ` Kashyap Desai
2019-09-19 16:13         ` Damien Le Moal
2019-09-21 15:26   ` [blk] b91f4a426e: fio.write_bw_MBps -9.3% regression kernel test robot
2019-09-21 15:26     ` kernel test robot
2019-09-19  9:56 ` [RFC PATCH 0/2] blk-mq I/O scheduling fixes Liu, Sunny
2019-09-19 10:03   ` Damien Le Moal [this message]
     [not found]     ` <BJXPR01MB0296594F3E478B5BFD4DA2ABF4890@BJXPR01MB0296.CHNPR01.prod.partner.outlook.cn>
2019-09-19 12:44       ` Damien Le Moal
2019-09-19 12:54         ` Liu, Sunny
2019-09-19 12:57 ` Hans Holmberg
2019-09-19 17:48 ` Jens Axboe
2019-09-19 21:11   ` Damien Le Moal

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=BYAPR04MB581634BD1F85CA9768AC780FE7890@BYAPR04MB5816.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=Hans.Holmberg@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ping.liu@lenovonetapp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.