On 12/14/12 20:55, scameron@xxxxxxxxxxxxxxxxxx wrote:
It's not so much that they are re-ordered as that there is no controlled ordering to begin with because multiple cpus are submitting to multiple hardware queues concurrently. If you have 12 requests coming in on 12 cpus to 12 hardware queues to the device, it's going to be racy as to which request is processed first by the device -- and this is fine, the hardware queues are independent of one another and do not need to worry about each other. This is all to provide a means of getting enough commands on the device to actually keep it busy. A single cpu can't do it, the device is too fast. If you have ordering dependencies such that request A must complete before request B completes, then don't submit A and B concurrently, because if you do submit them concurrently, you cannot tell whether A or B will arrive into the device first because they may go into it via different hardware queues.
It depends on how these multiple queues are used. If each queue would e.g. be associated with a disjoint LBA range of the storage device then there wouldn't be a risk of request reordering due to using multiple hardware queues.
Bart. -- 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
