From: Ming Lei <ming.lei@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
John Garry <john.garry@huawei.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:24:09 +0800 [thread overview]
Message-ID: <20180130012408.GD17176@ming.t460p> (raw)
In-Reply-To: <1517259390.3969.41.camel@HansenPartnership.com>
On Mon, Jan 29, 2018 at 12:56:30PM -0800, James Bottomley wrote:
> On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote:
> [...]
> > 2. When to enable SCSI_MQ at default again?
>
> I'm not sure there's much to discuss ... I think the basic answer is as
> soon as Christoph wants to try it again.
I guess Christoph still need to evaluate if there are existed issues or
blockers before trying it again. And more input may be got from F2F
discussion, IMHO.
>
> > 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.
>
> Is the blocker bug just not closed because no-one thought to do it:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=178381
>
> (we have confirmed that this issue is now fixed with the original
> reporter?)
>From a developer view, this issue is fixed by the following commit:
3a0a52997(block, scsi: Make SCSI quiesce and resume work reliably),
and it is verified by kernel list reporter.
>
> And did the Huawei guy (Jonathan Cameron) confirm his performance issue
> was fixed (I don't think I saw email that he did)?
Last time I talked with John Garry about the issue, and the merged .get_budget
based patch improves much on the IO performance, but there is still a bit gap
compared with legacy path. Seems a driver specific issue, remembered that removing
a driver's lock can improve performance much.
Garry, could you provide further update on this issue?
Thanks,
Ming
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:24:09 +0800 [thread overview]
Message-ID: <20180130012408.GD17176@ming.t460p> (raw)
In-Reply-To: <1517259390.3969.41.camel@HansenPartnership.com>
On Mon, Jan 29, 2018@12:56:30PM -0800, James Bottomley wrote:
> On Mon, 2018-01-29@23:46 +0800, Ming Lei wrote:
> [...]
> > 2. When to enable SCSI_MQ at default again?
>
> I'm not sure there's much to discuss ... I think the basic answer is as
> soon as Christoph wants to try it again.
I guess Christoph still need to evaluate if there are existed issues or
blockers before trying it again. And more input may be got from F2F
discussion, IMHO.
>
> > 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.
>
> Is the blocker bug just not closed because no-one thought to do it:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=178381
>
> (we have confirmed that this issue is now fixed with the original
> reporter?)
>From a developer view, this issue is fixed by the following commit:
3a0a52997(block, scsi: Make SCSI quiesce and resume work reliably),
and it is verified by kernel list reporter.
>
> And did the Huawei guy (Jonathan Cameron) confirm his performance issue
> was fixed (I don't think I saw email that he did)?
Last time I talked with John Garry about the issue, and the merged .get_budget
based patch improves much on the IO performance, but there is still a bit gap
compared with legacy path. Seems a driver specific issue, remembered that removing
a driver's lock can improve performance much.
Garry, could you provide further update on this issue?
Thanks,
Ming
next prev parent reply other threads:[~2018-01-30 1:24 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 ` [Lsf-pc] " Ming Lei
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 [this message]
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=20180130012408.GD17176@ming.t460p \
--to=ming.lei@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Linux-scsi@vger.kernel.org \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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.