#
256843 |
|
21-Oct-2013 |
mav |
Merge CAM locking changes from the projects/camlock branch to radically reduce lock congestion and improve SMP scalability of the SCSI/ATA stack, preparing the ground for the coming next GEOM direct dispatch support.
Replace big per-SIM locks with bunch of smaller ones: - per-LUN locks to protect device and peripheral drivers state; - per-target locks to protect list of LUNs on target; - per-bus locks to protect reference counting; - per-send queue locks to protect queue of CCBs to be sent; - per-done queue locks to protect queue of completed CCBs; - remaining per-SIM locks now protect only HBA driver internals.
While holding LUN lock it is allowed (while not recommended for performance reasons) to take SIM lock. The opposite acquisition order is forbidden. All the other locks are leaf locks, that can be taken anywhere, but should not be cascaded. Many functions, such as: xpt_action(), xpt_done(), xpt_async(), xpt_create_path(), etc. are no longer require (but allow) SIM lock to be held.
To keep compatibility and solve cases where SIM lock can't be dropped, all xpt_async() calls in addition to xpt_done() calls are queued to completion threads for async processing in clean environment without SIM lock held.
Instead of single CAM SWI thread, used for commands completion processing before, use multiple (depending on number of CPUs) threads. Load balanced between them using "hash" of the device B:T:L address.
HBA drivers that can drop SIM lock during completion processing and have sufficient number of completion threads to efficiently scale to multiple CPUs can use new function xpt_done_direct() to avoid extra context switch. Make ahci(4) driver to use this mechanism depending on hardware setup.
Sponsored by: iXsystems, Inc. MFC after: 2 months
|
#
244014 |
|
08-Dec-2012 |
ken |
Fix a device departure bug for the the pass(4), enc(4), sg(4) and ch(4) drivers.
The bug occurrs when a userland process has the driver instance open and the underlying device goes away. We get the devfs callback that the device node has been destroyed, but not all of the closes necessary to fully decrement the reference count on the CAM peripheral.
The reason is that once devfs calls back and says the device has been destroyed, it is moved off to deadfs, and devfs guarantees that there will be no more open or close calls. So the solution is to keep track of how many outstanding open calls there are on the device, and just release that many references when we get the callback from devfs.
scsi_pass.c, scsi_enc.c, scsi_enc_internal.h: Add an open count to the softc in these drivers. Increment it on open and decrement it on close.
When we get a devfs callback to say that the device node has gone away, decrement the peripheral reference count by the number of still outstanding opens.
Make sure we don't access the peripheral with cam_periph_unlock() after what might be the final call to cam_periph_release_locked(). The peripheral might have been freed, and we will be dereferencing freed memory.
scsi_ch.c, scsi_sg.c: For the ch(4) and sg(4) drivers, add the same changes described above, and in addition, fix another bug that was previously fixed in the pass(4) and enc(4) drivers.
These drivers were calling destroy_dev() from their cleanup routine, but that could cause a deadlock because the cleanup routine could be indirectly called from the driver's close routine. This would cause a deadlock, because the device node is being held open by the active close call, and can't be destroyed.
Sponsored by: Spectra Logic Corporation MFC after: 1 week
|
#
235911 |
|
24-May-2012 |
mav |
MFprojects/zfsd: Revamp the CAM enclosure services driver. This updated driver uses an in-kernel daemon to track state changes and publishes physical path location information\for disk elements into the CAM device database.
Sponsored by: Spectra Logic Corporation Sponsored by: iXsystems, Inc. Submitted by: gibbs, will, mav
|