From: Ming Lei <ming.lei@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: linux-block@vger.kernel.org, lsf-pc@lists.linux-foundation.org,
linux-nvme@lists.infradead.org, Linux-scsi@vger.kernel.org
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Two blk-mq related topics
Date: Tue, 30 Jan 2018 09:27:57 +0800 [thread overview]
Message-ID: <20180130012755.GE17176@ming.t460p> (raw)
In-Reply-To: <20180129204031.GA5499@redhat.com>
On Mon, Jan 29, 2018 at 03:40:31PM -0500, Mike Snitzer wrote:
> On Mon, Jan 29 2018 at 10:46am -0500,
> Ming Lei <ming.lei@redhat.com> wrote:
>
> > 2. When to enable SCSI_MQ at default again?
> >
> > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In V4.13-rc1,
> > it is enabled at default, but later the patch is reverted in V4.13-rc7, and
> > becomes disabled at default too.
> >
> > Now both the original reported PM issue(actually SCSI quiesce) and the
> > sequential IO performance issue have been addressed. And MQ IO schedulers
> > are ready too for traditional disks. Are there other issues to be addressed
> > for enabling SCSI_MQ at default? When can we do that again?
> >
> > Last time, the two issues were reported during V4.13 dev cycle just when it is
> > enabled at default, that seems if SCSI_MQ isn't enabled at default, it wouldn't
> > be exposed to run/tested completely & fully.
> >
> > So if we continue to disable it at default, maybe it can never be exposed to
> > full test/production environment.
>
> I was going to propose revisiting this as well.
>
> I'd really like to see all the old .request_fn block core code removed.
Yeah, that should be a final goal, but may take a bit long.
>
> But maybe we take a first step of enabling:
> CONFIG_SCSI_MQ_DEFAULT=Y
> CONFIG_DM_MQ_DEFAULT=Y
Maybe you can remove legacy path from DM_RQ first, and take your
original approach to allow DM/MQ over legacy underlying driver,
seems we discussed this topic before, :-)
Thanks,
Ming
_______________________________________________
Lsf-pc mailing list
Lsf-pc@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc
WARNING: multiple messages have this Message-ID (diff)
From: ming.lei@redhat.com (Ming Lei)
Subject: [LSF/MM TOPIC] Two blk-mq related topics
Date: Tue, 30 Jan 2018 09:27:57 +0800 [thread overview]
Message-ID: <20180130012755.GE17176@ming.t460p> (raw)
In-Reply-To: <20180129204031.GA5499@redhat.com>
On Mon, Jan 29, 2018@03:40:31PM -0500, Mike Snitzer wrote:
> On Mon, Jan 29 2018 at 10:46am -0500,
> Ming Lei <ming.lei@redhat.com> wrote:
>
> > 2. When to enable SCSI_MQ at default again?
> >
> > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In V4.13-rc1,
> > it is enabled at default, but later the patch is reverted in V4.13-rc7, and
> > becomes disabled at default too.
> >
> > Now both the original reported PM issue(actually SCSI quiesce) and the
> > sequential IO performance issue have been addressed. And MQ IO schedulers
> > are ready too for traditional disks. Are there other issues to be addressed
> > for enabling SCSI_MQ at default? When can we do that again?
> >
> > Last time, the two issues were reported during V4.13 dev cycle just when it is
> > enabled at default, that seems if SCSI_MQ isn't enabled at default, it wouldn't
> > be exposed to run/tested completely & fully.
> >
> > So if we continue to disable it at default, maybe it can never be exposed to
> > full test/production environment.
>
> I was going to propose revisiting this as well.
>
> I'd really like to see all the old .request_fn block core code removed.
Yeah, that should be a final goal, but may take a bit long.
>
> But maybe we take a first step of enabling:
> CONFIG_SCSI_MQ_DEFAULT=Y
> CONFIG_DM_MQ_DEFAULT=Y
Maybe you can remove legacy path from DM_RQ first, and take your
original approach to allow DM/MQ over legacy underlying driver,
seems we discussed this topic before, :-)
Thanks,
Ming
WARNING: multiple messages have this Message-ID (diff)
From: Ming Lei <ming.lei@redhat.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: lsf-pc@lists.linux-foundation.org, Linux-scsi@vger.kernel.org,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: [LSF/MM TOPIC] Two blk-mq related topics
Date: Tue, 30 Jan 2018 09:27:57 +0800 [thread overview]
Message-ID: <20180130012755.GE17176@ming.t460p> (raw)
In-Reply-To: <20180129204031.GA5499@redhat.com>
On Mon, Jan 29, 2018 at 03:40:31PM -0500, Mike Snitzer wrote:
> On Mon, Jan 29 2018 at 10:46am -0500,
> Ming Lei <ming.lei@redhat.com> wrote:
>
> > 2. When to enable SCSI_MQ at default again?
> >
> > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In V4.13-rc1,
> > it is enabled at default, but later the patch is reverted in V4.13-rc7, and
> > becomes disabled at default too.
> >
> > Now both the original reported PM issue(actually SCSI quiesce) and the
> > sequential IO performance issue have been addressed. And MQ IO schedulers
> > are ready too for traditional disks. Are there other issues to be addressed
> > for enabling SCSI_MQ at default? When can we do that again?
> >
> > Last time, the two issues were reported during V4.13 dev cycle just when it is
> > enabled at default, that seems if SCSI_MQ isn't enabled at default, it wouldn't
> > be exposed to run/tested completely & fully.
> >
> > So if we continue to disable it at default, maybe it can never be exposed to
> > full test/production environment.
>
> I was going to propose revisiting this as well.
>
> I'd really like to see all the old .request_fn block core code removed.
Yeah, that should be a final goal, but may take a bit long.
>
> But maybe we take a first step of enabling:
> CONFIG_SCSI_MQ_DEFAULT=Y
> CONFIG_DM_MQ_DEFAULT=Y
Maybe you can remove legacy path from DM_RQ first, and take your
original approach to allow DM/MQ over legacy underlying driver,
seems we discussed this topic before, :-)
Thanks,
Ming
next prev parent reply other threads:[~2018-01-30 1:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-29 15:46 [LSF/MM TOPIC] Two blk-mq related topics Ming Lei
2018-01-29 15:46 ` Ming Lei
2018-01-29 20:40 ` Mike Snitzer
2018-01-29 20:40 ` Mike Snitzer
2018-01-30 1:27 ` Ming Lei [this message]
2018-01-30 1:27 ` Ming Lei
2018-01-30 1:27 ` Ming Lei
2018-01-29 20:56 ` James Bottomley
2018-01-29 20:56 ` James Bottomley
2018-01-29 21:00 ` Jens Axboe
2018-01-29 21:00 ` Jens Axboe
2018-01-29 23:46 ` James Bottomley
2018-01-29 23:46 ` James Bottomley
2018-01-30 1:47 ` Jens Axboe
2018-01-30 1:47 ` Jens Axboe
2018-01-30 10:08 ` Johannes Thumshirn
2018-01-30 10:08 ` Johannes Thumshirn
2018-01-30 10:08 ` Johannes Thumshirn
2018-01-30 10:50 ` Mel Gorman
2018-01-30 10:50 ` Mel Gorman
2018-01-30 1:24 ` Ming Lei
2018-01-30 1:24 ` Ming Lei
2018-01-30 8:33 ` [Lsf-pc] " Martin Steigerwald
2018-01-30 8:33 ` Martin Steigerwald
2018-01-30 8:33 ` Martin Steigerwald
2018-01-30 10:33 ` John Garry
2018-01-30 10:33 ` John Garry
2018-01-30 10:33 ` John Garry
2018-02-07 10:55 ` John Garry
2018-02-07 10:55 ` John Garry
2018-02-07 10:55 ` John Garry
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=20180130012755.GE17176@ming.t460p \
--to=ming.lei@redhat.com \
--cc=Linux-scsi@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=snitzer@redhat.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.