Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Aug 2013 02:38:17 +0200
From:      Hans Petter Selasky <hps@bitfrost.no>
To:        Alexander Motin <mav@FreeBSD.org>
Cc:        Scott Long <scottl@FreeBSD.org>, Jeff Roberson <jeff@freebsd.org>, ken <ken@freebsd.org>, freebsd-hackers@FreeBSD.org, FreeBSD SCSI <freebsd-scsi@freebsd.org>, Steven Hartland <smh@FreeBSD.org>, "Justin T. Gibbs" <gibbs@FreeBSD.org>
Subject:   Re: New CAM locking preview
Message-ID:  <520D7479.3060505@bitfrost.no>
In-Reply-To: <520D4ADB.50209@FreeBSD.org>
References:  <520D4ADB.50209@FreeBSD.org>

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?

--HPS




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?520D7479.3060505>