Re: Slow I/O on USB media after commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6

Alan Stern
2019-11-05T18:31:51Z

On Tue, 5 Nov 2019, Andrea Vai wrote:

> Il giorno lun, 04/11/2019 alle 13.20 -0500, Alan Stern ha scritto:

> > You should be able to do something like this:
> >
> > cd linux
> > patch -p1 </path/to/patch2
> >
> > and that should work with no errors. You don't need to use git to
> > apply a patch.
> >
> > In case that patch2 file was mangled somewhere along the way, I
> > have
> > attached a copy to this message.
>
> Ok, so the "patch" command worked, the kernel compiled and ran, but
> the test still failed (273, 108, 104, 260, 177, 236, 179, 1123, 289,
> 873 seconds to copy a 500MB file, vs. ~30 seconds with the "good"
> kernel).
>
> Let me know what else could I do,

I'm out of suggestions. If anyone else knows how to make a kernel with
no legacy queuing support -- only multiqueue -- issue I/O requests
sequentially, please speak up.

In the absence of any responses, after a week or so I will submit a
patch to revert the f664a3cc17b7 ("scsi: kill off the legacy IO path")
commit.

Alan Stern