Messages in this thread | | | Date | Tue, 5 Nov 2019 13:31:46 -0500 (EST) | From | Alan Stern <> | Subject | Re: Slow I/O on USB media after commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6 |
| |
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
| |