[PATCH] 0/7 per scsi_device queue lock patches

[Patrick Mansfield <patmans@us.ibm.com>]

The following patches against recent 2.5.x bk (pulled on march 24, should
apply fine on top of 2.5.66) leads to splitting the scsi queue_lock into a
pre-scsi_device lock rather than the current per-scsi_host lock.

The first 2 patches were already posted and discussed, and include changes
based on that discussion.

Hopefully there are no major issues with the first 4 patches - I would
like to have them pushed for inclusion in 2.5.

Patches are incremental (they overlap).

Patch descriptions:

patch 1: starved changes - use a list_head for starved queue's
patch 2: add missing scsi_queue_next_request calls
patch 3: consolidate single_lun code (this code goes away with patch 7)
patch 4: cleanup/consolidate code in scsi_request_fn
patch 5: alloc a request_queue on each scsi_alloc_sdev call
patch 6: add and use a per-scsi_device queue_lock
patch 7: fix single_lun code for per-scsi_device queue_lock.

If you run with all patches applied let me know your results.

I've run tests across 20 drives and 2 qla 2300 adapters on an 8 CPU NUMAQ
system, using the feral driver with can_queue set to 50 and queue_depth
set to 16.

I ran with 20 processes, each process just continuously re-reads the first
block of a different disk (using O_DIRECT). Not much of a benchmark.

With all the patches applied (20 processes each reading 20000 times), I got:

1.03user 81.91system 0:28.46elapsed

Without patches:

1.09user 153.36system 0:34.61elapsed

If anyone wants, I can get vmstat or oprofile before/after results.

I ran some write-fsync tests (on file systems mounted across 20 drives),
but hitting can_queue without the starved changes causes variations in
performance numbers, and I'm getting IO hangs (with and without the above
patches, but more so without the patches). I haven't figured out what is
wrong. I'm also getting occasional hangs on boot (with or without patches,
NUMAQ + feral + isp 1020 + qla 2300). I have not had any problems on a
netfinity (more standard x86) box with an aic adapter.

Thanks.

-- Patrick Mansfield