All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: yangerkun <yangerkun@huawei.com>
Cc: damien.lemoal@wdc.com, axboe@kernel.dk,
	miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
	linux-block@vger.kernel.org, linux-mtd@lists.infradead.org,
	yi.zhang@huawei.com, yebin10@huawei.com, houtao1@huawei.com
Subject: Re: [QUESTION] blk_mq_freeze_queue in elevator_init_mq
Date: Wed, 17 Nov 2021 16:06:45 +0800	[thread overview]
Message-ID: <YZS4FYxtxYAXjtFJ@T590> (raw)
In-Reply-To: <d9113bf8-4654-cb04-f79c-38e11493cb2c@huawei.com>

On Wed, Nov 17, 2021 at 11:37:13AM +0800, yangerkun wrote:
> Nowdays we meet the boot regression while enable lots of mtdblock

What is your boot regression? Any dmesg log?

> compare with 4.4. The main reason was that the blk_mq_freeze_queue in
> elevator_init_mq will wait a RCU gap which want to make sure no IO will
> happen while blk_mq_init_sched.

There isn't RCU grace period implied in the blk_mq_freeze_queue() called
from elevator_init_mq(), because the .q_usage_counter works at atomic mode
at that time.

> 
> Other module like loop meets this problem too and has been fix with

Again, what is the problem?

> follow patches:
> 
>  2112f5c1330a loop: Select I/O scheduler 'none' from inside add_disk()
>  90b7198001f2 blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
> 
> They change the default IO scheduler for loop to 'none'. So no need to
> call blk_mq_freeze_queue and blk_mq_init_sched. But it seems not
> appropriate for mtdblocks. Mtdblocks can use 'mq-deadline' to help
> optimize the random write with the help of mtdblock's cache. Once change
> to 'none', we may meet the regression for random write.
> 
> commit 737eb78e82d52d35df166d29af32bf61992de71d
> Author: Damien Le Moal <damien.lemoal@wdc.com>
> Date:   Thu Sep 5 18:51:33 2019 +0900
> 
>     block: Delay default elevator initialization
> 
>     ...
> 
>     Additionally, to make sure that the elevator initialization is never
>     done while requests are in-flight (there should be none when the device
>     driver calls device_add_disk()), freeze and quiesce the device request
>     queue before calling blk_mq_init_sched() in elevator_init_mq().
>     ...
> 
> This commit add blk_mq_freeze_queue in elevator_init_mq which try to
> make sure no in-flight request while we go through blk_mq_init_sched.
> But does there any drivers can leave IO alive while we go through
> elevator_init_mq？ And if no, maybe we can just remove this logical to
> fix the regression...

SCSI should have passthrough requests at that moment.



Thanks,
Ming


WARNING: multiple messages have this Message-ID (diff)
From: Ming Lei <ming.lei@redhat.com>
To: yangerkun <yangerkun@huawei.com>
Cc: damien.lemoal@wdc.com, axboe@kernel.dk,
	miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
	linux-block@vger.kernel.org, linux-mtd@lists.infradead.org,
	yi.zhang@huawei.com, yebin10@huawei.com, houtao1@huawei.com
Subject: Re: [QUESTION] blk_mq_freeze_queue in elevator_init_mq
Date: Wed, 17 Nov 2021 16:06:45 +0800	[thread overview]
Message-ID: <YZS4FYxtxYAXjtFJ@T590> (raw)
In-Reply-To: <d9113bf8-4654-cb04-f79c-38e11493cb2c@huawei.com>

On Wed, Nov 17, 2021 at 11:37:13AM +0800, yangerkun wrote:
> Nowdays we meet the boot regression while enable lots of mtdblock

What is your boot regression? Any dmesg log?

> compare with 4.4. The main reason was that the blk_mq_freeze_queue in
> elevator_init_mq will wait a RCU gap which want to make sure no IO will
> happen while blk_mq_init_sched.

There isn't RCU grace period implied in the blk_mq_freeze_queue() called
from elevator_init_mq(), because the .q_usage_counter works at atomic mode
at that time.

> 
> Other module like loop meets this problem too and has been fix with

Again, what is the problem?

> follow patches:
> 
>  2112f5c1330a loop: Select I/O scheduler 'none' from inside add_disk()
>  90b7198001f2 blk-mq: Introduce the BLK_MQ_F_NO_SCHED_BY_DEFAULT flag
> 
> They change the default IO scheduler for loop to 'none'. So no need to
> call blk_mq_freeze_queue and blk_mq_init_sched. But it seems not
> appropriate for mtdblocks. Mtdblocks can use 'mq-deadline' to help
> optimize the random write with the help of mtdblock's cache. Once change
> to 'none', we may meet the regression for random write.
> 
> commit 737eb78e82d52d35df166d29af32bf61992de71d
> Author: Damien Le Moal <damien.lemoal@wdc.com>
> Date:   Thu Sep 5 18:51:33 2019 +0900
> 
>     block: Delay default elevator initialization
> 
>     ...
> 
>     Additionally, to make sure that the elevator initialization is never
>     done while requests are in-flight (there should be none when the device
>     driver calls device_add_disk()), freeze and quiesce the device request
>     queue before calling blk_mq_init_sched() in elevator_init_mq().
>     ...
> 
> This commit add blk_mq_freeze_queue in elevator_init_mq which try to
> make sure no in-flight request while we go through blk_mq_init_sched.
> But does there any drivers can leave IO alive while we go through
> elevator_init_mq？ And if no, maybe we can just remove this logical to
> fix the regression...

SCSI should have passthrough requests at that moment.



Thanks,
Ming


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2021-11-17  8:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17  3:37 [QUESTION] blk_mq_freeze_queue in elevator_init_mq yangerkun
2021-11-17  3:37 ` yangerkun
2021-11-17  4:11 ` Bart Van Assche
2021-11-17  4:11   ` Bart Van Assche
2021-11-17  8:39   ` yangerkun
2021-11-17  8:39     ` yangerkun
2021-11-17  8:06 ` Ming Lei [this message]
2021-11-17  8:06   ` Ming Lei
2021-11-17  8:37   ` yangerkun
2021-11-17  8:37     ` yangerkun
2021-11-17  9:00   ` yangerkun
2021-11-17  9:00     ` yangerkun
2021-11-17 10:19     ` Ming Lei
2021-11-17 10:19       ` Ming Lei
2021-11-18 13:12       ` yangerkun
2021-11-18 13:12         ` yangerkun

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=YZS4FYxtxYAXjtFJ@T590 \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@wdc.com \
    --cc=houtao1@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    --cc=yangerkun@huawei.com \
    --cc=yebin10@huawei.com \
    --cc=yi.zhang@huawei.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.