linux-kernel - Re: Device or HBA level QD throttling creates randomness in sequetial workload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 30 Jan 2017 11:29:14 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Kashyap Desai <kashyap.desai@...adcom.com>,
        Bart Van Assche <Bart.VanAssche@...disk.com>,
        osandov@...ndov.com
Cc:     linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        hch@...radead.org, linux-block@...r.kernel.org,
        paolo.valente@...aro.org
Subject: Re: Device or HBA level QD throttling creates randomness in sequetial
 workload

On 01/30/2017 11:28 AM, Kashyap Desai wrote:
>> -----Original Message-----
>> From: Jens Axboe [mailto:axboe@...nel.dk]
>> Sent: Monday, January 30, 2017 10:03 PM
>> To: Bart Van Assche; osandov@...ndov.com; kashyap.desai@...adcom.com
>> Cc: linux-scsi@...r.kernel.org; linux-kernel@...r.kernel.org;
>> hch@...radead.org; linux-block@...r.kernel.org; paolo.valente@...aro.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