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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520D7479.3060505>