On 03/18/2010 04:19 AM, Douglas Gilbert wrote: > bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: >> http://bugzilla.kernel.org/show_bug.cgi?id=15565 >> >> Summary: SCSI Generic queueing completes commands in reverse >> order >> Product: IO/Storage >> Version: 2.5 >> Kernel Version: 2.6.18-2.6.32 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: SCSI >> AssignedTo: linux-scsi@xxxxxxxxxxxxxxx >> ReportedBy: mh-linux-kernel@xxxxxxxx >> Regression: No >> >> >> I've noticed after queueing the first command, subsequent commands >> appear to be executed and complete in reverse order. The SCSI Generic >> HOWTO says "By default, read() will return the oldest completed >> request that is queued up." >> >> This could also be a performance defect if it's what's really >> happening since it isn't desirable behavior if, for example, ios are >> typically ordered by lba and issued one at a time by kernel to a non >> queueing block device. >> >> This reverse order behavior is trivial to reproduce; just queue 16 >> concurrent INQUIRY commands. The following are typical results I get >> from initially queueing 16 READ_10 commands. >> >> Completion Command # hdr.driver_duration (us) >> Order >> 1 22 14979 >> 2 20 14981 >> 3 19 14982 >> 4 17 14984 >> 5 16 14985 >> 6 15 14986 >> 7 14 14988 >> 8 12 14990 >> 9 11 14991 >> 10 10 14992 >> > > I have been told that is a feature :-) > > The SCSI mid level processes commands from > pass-throughs (e.g. sg and bsg) in LIFO order. > For certain types of error processing it makes > sense. For READs and WRITEs it makes no sense. > I have fixed that for bsg long ago. There is a flag that you put: sg.flags = BSG_FLAG_Q_AT_TAIL; Which will do the by order, queue at tail. Zero was kept compatible to sg meaning "queue at head" i.e. jump the line. > Doug Gilbert > It could be added to sg as well if needed Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
