Re: Proposal for a scalable SCSI midlayer

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2014-02-26 at 11:59 +0100, Bart Van Assche wrote:
> On 02/23/14 21:10, James Bottomley wrote:
> > Right ... my ideal here if we can achieve it would be lockless threaded
> > models, where we could make guarantees like single thread of execution
> > per command, so all command state could be lockless.
> 
> This approach sounds interesting but could be challenging to implement.
> With this approach it would no longer be safe to access the SCSI command
> state from interrupt nor from tasklet context.

I don't think so: a SCSI command has to be in a distinct state, either
preparing, dispatching (at HBA) or returning (or a variety of states in
between).  It can't be in more than one state, so we can still guarantee
the per command variables can be accessed locklessly from any context
because if more than one CPU is operating on it simultaneously, we just
broke the state machine.

The challenge comes from the device variables:  a device can have a
bunch of commands in various states.  However, if we can guarantee
single CPU dispatch per device queue, then we could also use lockless
plus sloppy counters on the device variables because the CPU can only be
in a single state per queue even if multiple commands in the queue are
in different states.  The times we need to see the per-queue state
rolled up are fairly well defined, so we can shift the expense of the
rollup operation to the aggregation phase, hence sloppy counters.


James


>  That means that the I/O
> completion path would have to be modified such that instead of using an
> IPI to invoke a tasklet at the CPU that submitted the SCSI command a new
> mechanism would have to be used that causes the I/O completion code to
> run directly on the context of the thread that submitted the SCSI command.
> 
> Bart.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html