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.
Alan Stern
