From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Sender: arndbergmann@gmail.com In-Reply-To: References: From: Arnd Bergmann Date: Fri, 31 Mar 2017 10:43:43 +0200 Message-ID: Subject: Re: Outstanding MQ questions from MMC To: Ulf Hansson Cc: Linus Walleij , "linux-mmc@vger.kernel.org" , linux-block@vger.kernel.org, Jens Axboe , Christoph Hellwig , Adrian Hunter , Paolo Valente Content-Type: text/plain; charset=UTF-8 List-ID: On Thu, Mar 30, 2017 at 6:39 PM, Ulf Hansson wrote: > On 30 March 2017 at 14:42, Arnd Bergmann wrote: >> On Wed, Mar 29, 2017 at 5:09 AM, Linus Walleij wrote: >>> In MQ, I have simply locked the host on the first request and then I never >>> release it. Clearly this does not work. I am uncertain on how to handle this >>> and whether MQ has a way to tell us that the queue is empty so we may release >>> the host. I toyed with the idea to just set up a timer, but a "queue >>> empty" callback >>> from the block layer is what would be ideal. >> >> Would it be possible to change the userspace code to go through >> the block layer instead and queue a request there, to avoid having >> to lock the card at all? > > That would be good from an I/O scheduling point of view, as it would > avoid one side being able to starve the other. > > However, we would still need a lock, as we also have card detect work > queue, which also needs to claim the host when it polls for removable > cards. Hmm, In theory the card-detect work queue should not be active at the same time as any I/O, but I see you point. Could the card-detect wq perhaps also use the blk queue for sending a special request that triggers the detection logic? Alternatively, I had this idea that we could translate blk requests into mmc commands and then have a (short fixed length) set of outstanding mmc commands in the device that always get done in order. The card detect and the user space I/O would then directly put mmc commands onto the command queue, as would the blk-mq scheduler. You still need a lock to access that command queue, but the mmc host would just always pick the next command off the list when one command completes. This also lets you integrate packed commands: if the next outstanding command is the same type as the request coming in from blk-mq, you can merge it into a single mmc command to be submitted together, otherwise it gets deferred. Arnd