On Fri, Nov 08, 2019 at 08:42:53AM +0000, Damien Le Moal wrote: > On 2019/11/08 4:00, Andrea Vai wrote: > > [Sorry for the duplicate message, it didn't reach the lists due to > > html formatting] > > Il giorno gio 7 nov 2019 alle ore 08:54 Damien Le Moal > > <Damien.LeMoal@xxxxxxx> ha scritto: > >> > >> On 2019/11/07 16:04, Andrea Vai wrote: > >>> Il giorno mer, 06/11/2019 alle 22.13 +0000, Damien Le Moal ha scritto: > >>>> > >>>> > >>>> Please simply try your write tests after doing this: > >>>> > >>>> echo mq-deadline > /sys/block/<name of your USB > >>>> disk>/queue/scheduler > >>>> > >>>> And confirm that mq-deadline is selected with: > >>>> > >>>> cat /sys/block/<name of your USB disk>/queue/scheduler > >>>> [mq-deadline] kyber bfq none > >>> > >>> ok, which kernel should I test with this: the fresh git cloned, or the > >>> one just patched with Alan's patch, or doesn't matter which one? > >> > >> Probably all of them to see if there are any differences. > > > > with both kernels, the output of > > cat /sys/block/sdh/queue/schedule > > > > already contains [mq-deadline]: is it correct to assume that the echo > > command and the subsequent testing is useless? What to do now? > > Probably, yes. Have you obtained a blktrace of the workload during these > tests ? Any significant difference in the IO pattern (IO size and > randomness) and IO timing (any device idle time where the device has no > command to process) ? Asking because the problem may be above the block > layer, with the file system for instance. You may get the IO pattern via the previous trace https://lore.kernel.org/linux-usb/20190710024439.GA2621@ming.t460p/ IMO, if it is related write order, one possibility could be that the queue lock is killed in .make_request_fn(). Thanks, Ming
