[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56E66F21.2050308@suse.de>
Date: Mon, 14 Mar 2016 08:58:25 +0100
From: Hannes Reinecke <hare@...e.de>
To: Finn Thain <fthain@...egraphics.com.au>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Michael Schmitz <schmitzmic@...il.com>,
linux-m68k@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: Ondrej Zary <linux@...nbow-software.org>,
Sam Creasey <sammy@...my.net>
Subject: Re: [PATCH 21/22] atari_scsi: Allow can_queue to be increased for
Falcon
On 03/14/2016 05:27 AM, Finn Thain wrote:
> The benefit of limiting can_queue to 1 is that atari_scsi shares the
> ST DMA chip more fairly with other drivers (e.g. falcon-ide).
>
> Unfortunately, this can limit SCSI bus utilization. On systems without
> IDE, atari_scsi should issue SCSI commands whenever it can arbitrate for
> the bus. Make that possible by making can_queue configurable.
>
> Signed-off-by: Finn Thain <fthain@...egraphics.com.au>
>
> ---
> drivers/scsi/atari_scsi.c | 83 ++++++++++++----------------------------------
> 1 file changed, 22 insertions(+), 61 deletions(-)
>
Hmm. We actually have a similar reasoning in the aic7xxx driver,
where the driver core wants to setup pointers to the _next_ command.
So maybe it makes sense to add a pointer to the 'next' command
somewhere in the NCR core structure, to be submitted whenever bus
arbitration tells you so?
But in the end it really looks like a real issue somewhere in the
code, be it the driver or the block/scsi layer.
Nevertheless, setting it to '1' is certainly the correct way here.
Reviewed-by: Hannes Reinecke <hare@...e.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@...e.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
Powered by blists - more mailing lists