From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <23155.45114.317289.396546@quad.stoffel.home> Date: Thu, 1 Feb 2018 19:26:34 -0500 From: "John Stoffel" To: Bart Van Assche Cc: "snitzer\@redhat.com" , "linux-block\@vger.kernel.org" , "axboe\@kernel.dk" , "dm-devel\@redhat.com" , "linux-nvme\@lists.infradead.org" , "linux-scsi\@vger.kernel.org" Subject: Re: [dm-devel] [PATCH V4] blk-mq: introduce BLK_STS_DEV_RESOURCE In-Reply-To: <1517262713.2687.56.camel@wdc.com> References: <20180129203300.50595-1-snitzer@redhat.com> <1517260932.2687.42.camel@wdc.com> <20180129214446.GD5744@redhat.com> <1517262713.2687.56.camel@wdc.com> List-ID: >>>>> "Bart" == Bart Van Assche writes: Bart> On Mon, 2018-01-29 at 16:44 -0500, Mike Snitzer wrote: >> But regardless of which wins the race, the queue will have been run. >> Which is all we care about right? Bart> Running the queue is not sufficient. With this patch applied it can happen Bart> that the block driver returns BLK_STS_DEV_RESOURCE, that the two or more Bart> concurrent queue runs finish before sufficient device resources are available Bart> to execute the request and that blk_mq_delay_run_hw_queue() does not get Bart> called at all. If no other activity triggers a queue run, e.g. request Bart> completion, this will result in a queue stall. Doesn't this argue that you really want some sort of completions to be run in this case instead? Instead of busy looping or waiting for a set amount of time, just fire off a callback to run once you have the resources available, no? I can't provide any code examples, I don't know the code base nearly well enough. John