From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ming.lei@redhat.com" <ming.lei@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"axboe@fb.com" <axboe@fb.com>, "hare@suse.com" <hare@suse.com>,
"holger@applied-asynchrony.com" <holger@applied-asynchrony.com>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>
Subject: Re: [PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle
Date: Tue, 5 Dec 2017 16:41:46 +0000 [thread overview]
Message-ID: <1512492105.2660.22.camel@wdc.com> (raw)
In-Reply-To: <20171205162825.GA23788@ming.t460p>
On Wed, 2017-12-06 at 00:28 +0800, Ming Lei wrote:
> This is still a workaround for RESTART, see my comment before:
>
> https://marc.info/?l=linux-block&m=151217500929341&w=2
A quote from that e-mail: "The theory about using BLK_MQ_S_SCHED_RESTART in
current way is that we mark it after requests are added to hctx->dispatch".
Reading that makes me wonder whether you understand the purpose of the
BLK_MQ_S_SCHED_RESTART flag? That flag is not set after requests are added
to the dispatch list but after requests have been *removed*. The purpose of
that flag is to detect whether another thread has run the queue after
requests were removed from the dispatch list and before these were readded.
If so, the queue needs to be rerun.
Bart.
next prev parent reply other threads:[~2017-12-05 16:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 7:52 [PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle Ming Lei
2017-12-05 14:29 ` Johannes Thumshirn
2017-12-05 16:16 ` Bart Van Assche
2017-12-05 16:08 ` Bart Van Assche
2017-12-05 16:28 ` Ming Lei
2017-12-05 16:41 ` Bart Van Assche [this message]
2017-12-05 16:45 ` Ming Lei
2017-12-06 1:52 ` Ming Lei
2017-12-06 16:07 ` Bart Van Assche
2017-12-07 1:31 ` Ming Lei
2017-12-07 21:11 ` Bart Van Assche
2017-12-08 0:36 ` Ming Lei
2017-12-07 21:06 ` Bart Van Assche
2017-12-08 0:50 ` Ming Lei
2017-12-06 23:10 ` Holger Hoffstätte
2017-12-07 1:40 ` Ming Lei
2017-12-08 0:54 ` Martin K. Petersen
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=1512492105.2660.22.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=axboe@fb.com \
--cc=hare@suse.com \
--cc=hch@infradead.org \
--cc=holger@applied-asynchrony.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox