Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Aug 2013 02:38:17 +0200
From:      Hans Petter Selasky <>
To:        Alexander Motin <>
Cc:        Scott Long <>, Jeff Roberson <>, ken <>,, FreeBSD SCSI <>, Steven Hartland <>, "Justin T. Gibbs" <>
Subject:   Re: New CAM locking preview
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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?


Want to link to this message? Use this URL: <>