[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171208003637.GA21488@ming.t460p>
Date: Fri, 8 Dec 2017 08:36:38 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Bart Van Assche <Bart.VanAssche@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"hch@...radead.org" <hch@...radead.org>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"axboe@...com" <axboe@...com>, "hare@...e.com" <hare@...e.com>,
"holger@...lied-asynchrony.com" <holger@...lied-asynchrony.com>,
"jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>
Subject: Re: [PATCH] SCSI: run queue if SCSI device queue isn't ready and
queue is idle
On Thu, Dec 07, 2017 at 09:11:54PM +0000, Bart Van Assche wrote:
> On Thu, 2017-12-07 at 09:31 +0800, Ming Lei wrote:
> > But if you always call blk_mq_sched_mark_restart_hctx() before a new
> > dispatch, that may affect performance on NVMe which may never trigger
> > BLK_STS_RESOURCE.
>
> Hmm ... only the SCSI core implements .get_budget() and .put_budget() and
> I proposed to insert a blk_mq_sched_mark_restart_hctx() call under "if
> (q->mq_ops->get_budget)". In other words, I proposed to insert a
> blk_mq_sched_mark_restart_hctx() call in a code path that is never triggered
> by the NVMe driver. So I don't see how the change I proposed could affect
> the performance of the NVMe driver?
You only add the check on none scheduler, right?
But this race isn't related with scheduler, that means it can't fix the
race with other schedulers.
I have test case to trigger this issue on both none and mq-deadline, and
my patch fixes them all.
Thanks,
Ming
Powered by blists - more mailing lists