From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: Device or HBA level QD throttling creates randomness in sequetial workload To: Kashyap Desai , Bart Van Assche , osandov@osandov.com References: <2d656e9c9fbde7206e40a635c61a6084@mail.gmail.com> <298b6ff6-9feb-4b70-ec4c-d1295a0e1f41@kernel.dk> <1485793840.2712.1.camel@sandisk.com> <22a9792c-098d-eb8d-b7d4-87a79cf1d31f@kernel.dk> <6325b0024b3cb401fcd1aed782b7b14d@mail.gmail.com> Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, hch@infradead.org, linux-block@vger.kernel.org, paolo.valente@linaro.org From: Jens Axboe Message-ID: <261c6afd-5974-c55c-371b-c2c047e0e5b0@kernel.dk> Date: Mon, 30 Jan 2017 11:29:14 -0700 MIME-Version: 1.0 In-Reply-To: <6325b0024b3cb401fcd1aed782b7b14d@mail.gmail.com> Content-Type: text/plain; charset=utf-8 List-ID: On 01/30/2017 11:28 AM, Kashyap Desai wrote: >> -----Original Message----- >> From: Jens Axboe [mailto:axboe@kernel.dk] >> Sent: Monday, January 30, 2017 10:03 PM >> To: Bart Van Assche; osandov@osandov.com; kashyap.desai@broadcom.com >> Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; >> hch@infradead.org; linux-block@vger.kernel.org; paolo.valente@linaro.org >> Subject: Re: Device or HBA level QD throttling creates randomness in >> sequetial workload >> >> On 01/30/2017 09:30 AM, Bart Van Assche wrote: >>> On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: >>>> - if (atomic_inc_return(&instance->fw_outstanding) > >>>> - instance->host->can_queue) { >>>> - atomic_dec(&instance->fw_outstanding); >>>> - return SCSI_MLQUEUE_HOST_BUSY; >>>> - } >>>> + if (atomic_inc_return(&instance->fw_outstanding) > > safe_can_queue) { >>>> + is_nonrot = blk_queue_nonrot(scmd->device->request_queue); >>>> + /* For rotational device wait for sometime to get fusion >>>> + command >>>> from pool. >>>> + * This is just to reduce proactive re-queue at mid layer >>>> + which is >>>> not >>>> + * sending sorted IO in SCSI.MQ mode. >>>> + */ >>>> + if (!is_nonrot) >>>> + udelay(100); >>>> + } >>> >>> The SCSI core does not allow to sleep inside the queuecommand() >>> callback function. >> >> udelay() is a busy loop, so it's not sleeping. That said, it's obviously > NOT a >> great idea. We want to fix the reordering due to requeues, not introduce >> random busy delays to work around it. > > Thanks for feedback. I do realize that udelay() is going to be very odd > in queue_command call back. I will keep this note. Preferred solution is > blk mq scheduler patches. It's coming in 4.11, so you don't have to wait long. -- Jens Axboe