Messages in this thread | | | Date | Tue, 15 Mar 2016 19:27:49 +1100 (AEDT) | From | Finn Thain <> | Subject | Re: [PATCH 20/22] atari_scsi: Set a reasonable default for cmd_per_lun |
| |
On Tue, 15 Mar 2016, Hannes Reinecke wrote:
> On 03/15/2016 04:27 AM, Finn Thain wrote: > > > > On Mon, 14 Mar 2016, Hannes Reinecke wrote: > > > >> On 03/14/2016 05:27 AM, Finn Thain wrote: > >>> This setting does not need to be conditional on Atari ST or TT. > >>> > >>> Without TCQ support, cmd_per_lun == 2 is probably reasonable... > >>> > >>> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> > >>> > >>> --- > >>> drivers/scsi/atari_scsi.c | 3 +-- > >>> 1 file changed, 1 insertion(+), 2 deletions(-) > >>> > >>> Index: linux/drivers/scsi/atari_scsi.c > >>> =================================================================== > >>> --- linux.orig/drivers/scsi/atari_scsi.c 2016-03-14 15:26:45.000000000 +1100 > >>> +++ linux/drivers/scsi/atari_scsi.c 2016-03-14 15:26:55.000000000 +1100 > >>> @@ -750,6 +750,7 @@ static struct scsi_host_template atari_s > >>> .eh_abort_handler = atari_scsi_abort, > >>> .eh_bus_reset_handler = atari_scsi_bus_reset, > >>> .this_id = 7, > >>> + .cmd_per_lun = 2, > >>> .use_clustering = DISABLE_CLUSTERING, > >>> .cmd_size = NCR5380_CMD_SIZE, > >>> }; > >> _2_ ? Are you being overly cheeky here? > >> I sincerely doubt the driver is capable of submitting two > >> simultaneous commands ... > > > > Right. The LLD has LU busy flags to prevent a LU from being issued > > more than one command. > > > >> Care to explain? > > > > It seemed harmless and it is consistent with the all of the other 5380 > > drivers. > > > > I don't know why it was done that way. Perhaps it was done to create a > > pipeline. That is, to keep a small number of commands in the LLD issue > > queue so that the NCR5380_main() work item does not have to terminate > > and then get requeued needlessly. > > > Like I suspected. > While I'm aware of the reasoning, I sincerely doubt whether it makes any > difference in real life. > After all, a 'BUSY' return value still relies on someone kicking the > queue so that the next command can be submitted.
Well, it is not queuecommand returning SCSI_MLQUEUE_HOST_BUSY. I assume it is scsi_request_fn() bailing out when !scsi_dev_queue_ready().
> So it's not much different from using a queuedepth of '1' and use the > 'official' way. > > Have you done any benchmarking here?
I have now.
> Would be very interesting to check if it makes a difference in real > life ...
It seems that the work item startup and shutdown overhead does make a difference on machines where cycles are scarce.
Using mac_scsi on a 25 MHz 68030 I made some test runs of # dd if=/dev/sda of=/dev/null count=4096 and the difference is measurable (effect size is 9+ standard deviations).
cmd_per_lun = 2 is about 3.0% faster than cmd_per_lun = 1. cmd_per_lun = 4 is about 3.7% faster than cmd_per_lun = 1.
Increasing cmd_per_lun to 16 (which equals can_queue) doesn't improve the timing.
I think the 'official' way (the default cmd_per_lun) would not hurt if the CPU was a bit faster.
Now that you've got me to test it I think 4 is probably the best for mac_scsi and atari_scsi. When I send v2 I will change patch 20 and 22 accordingly.
--
> > Cheers, > > Hannes >
| |