On Fri, 2010-09-17 at 12:32 +0200, Bart Van Assche wrote: > On Fri, Sep 17, 2010 at 9:16 AM, Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > > > > > Not really ... look at the code path (in scsi.c:scsi_dispatch_cmd()). > > > We take the lock, then get the serial number (that would likley have to > > > be replaced with an atomic), check the state, call trace, call > > > > An atomic unfortunately usually doesn't scale much better than a spinlock. > > I suspect serials would need to be made optional, e.g. > > computing them lazily if really needed. > > We should be careful that the command processing order for commands > issued by different threads is not altered by removing the host lock, > at least for those SCSI commands where in-order processing matters. > There might be better solutions than a serial number though. We don't actually make any ordering guarantees at the top of the stack. The block layer originally did need internal ordering guarantees for barriers, but they were automatically preserved by the fact that the exit from the ioscheduler is single threaded. However, the barrier redo means that we no longer even need the single threaded guarantee ... and I suspect Jens is already thinking about multi threading the ioscheduler exit, which is also another good reason for reducing the locking footprint. James -- 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
