Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx> writes: [...] >> Unless I am reading the trace wrong there are 3 reads issued to 259,1 >> sectors 6144, 4096 and 2048 in that order. This is the order userspace >> is issuing the reads, so the trace matches what I would expect. But now >> you tell me that the mq-deadline scheduler should reorder the requests >> based on LBA? But maybe the ordering by LBA is only for writes? I'll >> rerun the test with writes. > > Nope. Reordering is for reads too. But reordering happens only if the > commands are issued in batch or if the drive is busy (all tags used) and > commands accumulate in the scheduler. > > If the user issues these reads one at a time, they will go through the > scheduler without reordering. You can see that with blktrace: > If you see a G-Q-I-D sequence for each read, then it is not a batch and > they are going through as is. If you see G-Q-I-G-Q-I-G-Q-I-D-D-D, then > that was a batch and the "D" should be ordered in increasing LBA, even if > the I (insert) where out of order. I see. Looking at the full trace it does show that only part of the series of the reversed requests from ublksrv are batched up. They are not submitted in one go from ublksrv. Thanks, Andreas
