Re: [PATCH] scsi, mptsas : drop scsi_host lock when calling mptsas_qcmd

[James Bottomley <James.Bottomley@suse.de>]

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@linux.intel.com> 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