forked from luck/tmp_suning_uos_patched
aedf349773
As previously reported via Michael Reed, the FC transport took a hit in 2.6.15 (perhaps a little earlier) when we solved a recursion error. There are 2 deadlocks occurring: - With scan and the delete items sharing the same workq, flushing the workq for the delete code was getting it stalled behind a very long running scan code path. - There's a deadlock where scsi_remove_target() has to sit behind scsi_scan_target() due to contention over the scan_lock(). This patch resolves the 1st deadlock and significantly reduces the odds of the second. So far, we have only replicated the 2nd deadlock on a highly-parallel SMP system. More on the 2nd deadlock in a following email. This patch reworks the transport to: - Only use the scsi host workq for scanning - Use 2 other workq's internally. One for deletions, the other for scheduled deletions. Originally, we tried this with a single workq, but the occassional flushes of the scheduled queues was hitting the second deadlock with a slightly higher frequency. In the future, we'll look at the LLDD's and the transport to see if we can get rid of this extra overhead. - When moving to the other workq's we tightened up some object states and some lock handling. - Properly syncs adds/deletes - minor code cleanups - directly reference fc_host_attrs, rather than through attribute macros - flush the right workq on delayed work cancel failures. Large kudos to Michael Reed who has been working this issue for the last month. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> |
||
---|---|---|
.. | ||
iscsi_if.h | ||
iscsi_proto.h | ||
scsi_cmnd.h | ||
scsi_dbg.h | ||
scsi_device.h | ||
scsi_devinfo.h | ||
scsi_driver.h | ||
scsi_eh.h | ||
scsi_host.h | ||
scsi_ioctl.h | ||
scsi_request.h | ||
scsi_tcq.h | ||
scsi_transport_fc.h | ||
scsi_transport_iscsi.h | ||
scsi_transport_sas.h | ||
scsi_transport_spi.h | ||
scsi_transport.h | ||
scsi.h | ||
scsicam.h | ||
sg_request.h | ||
sg.h | ||
srp.h |