On 2019/09/19 16:01, Alan Stern wrote:
> On Thu, 19 Sep 2019, Damien Le Moal wrote:
>
>>> This is exactly the sort of difference one might expect to see from
>>> the commit f664a3cc17b7 ("scsi: kill off the legacy IO path") you
>>> identified as the cause of the problem. With multiqueue I/O, it's not
>>> surprising to see multiple sequences of block numbers.
>>>
>>> Add it's not at all surprising that a consumer-grade USB storage device
>>> might do a much worse job of handling non-sequential writes than
>>> sequential ones.
>>>
>>> Which leads to a simple question for the SCSI or block-layer
>>> maintainers: Is there a sysfs setting Andrea can tweak which will
>>> effectively restrict a particular disk device down to a single I/O
>>> queue, forcing sequential access?
>>
>> The scheduling inefficiency you are seeing may be coming from the fact that
>> the
>> block layer does a direct issue of requests, bypassing the elevator, under
>> some
>> conditions. One of these is sync requests on a multiqueue device. We hit this
>> problem on Zoned disks which can easily return an error for write requests
>> without the elevator throttling writes per zones (zone write locking). This
>> problem was discovered by Hans (on CC).
>
> Is there any way for Andrea to check whether this is the underlying
> cause?>
>> I discussed this with Hannes yesterday and we think we have a fix, but we'll
>> need to do a lot of testing as all block devices are potentially impacted by
>> the
>> change, including stacked drivers (DM). Performance regression is scary with
>> any
>> change in that area (see blk_mq_make_request() and use of
>> blk_mq_try_issue_directly() vs blk_mq_sched_insert_request()).
>
> No doubt Andrea will be happy to test your fix when it's ready.
Hannes posted an RFC series:
https://www.spinics.net/lists/linux-scsi/msg133848.html
Andrea can try it. But If the USB device is not multi-queue, this fix will
probably have no effect.
Andrea,
What is the device in question ? Is it a USB external HDD ? SSD ? Flash key ?
Best regards.
--
Damien Le Moal
Western Digital Research
