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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
