New CAM locking preview

[Hans Petter Selasky]

On 08/15/13 23:40, Alexander Motin wrote:
> Hi.
>
> Last weeks I've made substantial progress on my CAM locking work. In
> fact, at this moment I think I've tied all loose ends good enough to
> consider the new design viable and implementation worth further testing
> and bug fixing. So I would like to ask for review of my work from
> everybody who interested in CAM internals.
>
> In short, my idea was to split single per-SIM lock, that creates huge
> congestion under high IOPS, into several smaller ones. So design I've
> finally chosen includes such locks:
>   1) New per-device (per-LUN) locks to protect state of the devices and
> respective periphs. In most cases peripheral drivers just use that lock
> instead of SIM lock used before, so code modification is minimal and
> straightforward.
>   2) New per-target lock to protect list of LUNs fetched from the device.
>   3) Old single per-SIM lock to protect SIM driver internals, but only
> that. No parts of CAM itself use that lock. Keeping it for SIMs allows
> to keep API and hopefully ABI compatibility. Reducing its scope allows
> to reduce congestion.
>   4) New per-SIM lock to protect SIM and device command queues. That
> allows execute queued commands from any context unrelated to other
> locks. Also this lock serializes accesses to sim_action() method for the
> most of commands, this allows to mostly avoid busy spilling on SIM lock
> collision.
>   5) New per-bus locks to protect target, device and periphs reference
> counters. It allows to create and destroy paths unrelated to other locks
> in any possible context.
>

Sounds very good! I assume you have tested USB mass storage device 
unplug during various file system operations?

--HPS