On Fri, Mar 25, 2011 at 12:45 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Mar 24, 2011 at 05:57:17PM -0700, Dan Williams wrote: >> I have been waiting for this issue to be raised. This was one of the >> first items brought up in our internal reviews of the Linux driver. >> Why does it still exist and what is the rationale for addressing it >> incrementally?: >> >> Starting with simple locking and then scaling it is arguably easier >> than unwinding a more complex locking scheme implemented too early in >> the design phase. > > I don't care about the lock scalability. The problem with a global > spinlock is that a lot of primitives that a driver needs need to block, > and with a global spinlock that's almost impossible to handle, as > you'd need to drop the lock, and have very little chance to figure > out what state it actually protects that now needs to be re-checked. In that sense the scope of what scic_lock protects is limited to the core/hardware state machines (essentially a controller firmware-like context). Anything that blocks or interfaces with an upper layer runs unlocked in the lldd layer, and we don't play any games of dropping the lock from the core. Cancelling and flushing timed events is really the only place where the lock gets in the way. Having a "timer_cancelled" flag for these few cases is the approach the core took over dropping the lock, del_timer_sync, and re-validating state. -- 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
