[8117] in linux-scsi channel archive
RE: scsi queue depth problem
daemon@ATHENA.MIT.EDU (Ralston, Steve)
Wed Feb 16 10:36:46 2000
Message-ID: <B2B3C90E45AED111B7B40001FA7E520A03833F60@exw-kansas.ks.lsil.com>
From: "Ralston, Steve" <steve.ralston@lsil.com>
To: "'Eric Youngdale'" <eric@andante.org>,
"'Douglas Gilbert'" <dgilbert@724.com>
Cc: linux-scsi@vger.rutgers.edu
Date: Wed, 16 Feb 2000 09:05:11 -0600
MIME-Version: 1.0
Content-Type: text/plain
> The quick-hack way to test this theory is to simply zero the
queue depth
> in scsi_release_commandblocks().
Bingo. I hacked:
SDpnt->queue_depth = 0;
into drivers/scsi/scsi.c::scsi_release_commandblocks() and
my problem went away. I am now back to queueing 64 deep
on my single device with this change.
Thanks,
-SteveR
> -----Original Message-----
> From: Eric Youngdale [SMTP:eric@andante.org]
> Sent: Tuesday, February 15, 2000 9:06 PM
> To: Ralston, Steve; 'Douglas Gilbert'
> Cc: linux-scsi@vger.rutgers.edu
> Subject: Re: scsi queue depth problem
>
>
> For a moment I thought I understood the problem. I added an entry in
> the host template for select_queue_depths, mainly to make the thing
> symmetric WRT all of the other entrypoints. Back when this stuff got
> added, we didn't have the lisp-like initializers, and as a result an
> addition of this sort would have required patching each and every
> low-level
> driver.
>
> Unfortunately I looked over my patches, and the thing I changed won't
> explain it.
>
> There was one other thing which I did that might explain the issue. I
> was cleaning up the way that scan_scsis() works, mainly to fix it so that
> it
> does less under-the-hood hacking of the underlying datastructures, and it
> essentially uses existing interfaces much more like the way that sd.c
> would,
> for example. When we are scanning the bus, I just force the queue depth
> to
> 1, as this is all we need for the purposes of scanning the bus. When I am
> finished scanning the bus for a device, I release the single commandblock,
> but I never reset the queue_depth for the device back to 0. It is
> theoretically possible that in the select_queue_depths function that a
> low-level driver would look at the queue depth for a device and decide
> that
> if the value were non-zero that it should leave it alone.
>
> The quick-hack way to test this theory is to simply zero the queue
> depth
> in scsi_release_commandblocks(). The real fix is to probably set the
> queue
> depth back to 0 in scan_scsis(), but first I would like to see
> confirmation
> that this explains the problem.
>
> -Eric
>
>
> ----- Original Message -----
> From: "Ralston, Steve" <steve.ralston@lsil.com>
> To: "'Douglas Gilbert'" <dgilbert@724.com>
> Cc: <eric@andante.org>; <linux-scsi@vger.rutgers.edu>
> Sent: Tuesday, February 15, 2000 7:17 PM
> Subject: RE: scsi queue depth problem
>
>
> > Yes, you gather correctly. :-)
> > I was just cruising along doing periodic kernel source tree
> > updates while working on the (SCSI) driver, and happened
> > to notice that beating on the disk, well "sounded different"
> > after updating from linux-2.3.42. When I tried to figure out why,
> > I noticed lack of [any] usual:
> > <6>mpiscsi: Queue depth now {2-64}.
> > debug printk's in my sysklog... Indicating to me that I'm
> > choked down to 1 deep.
> >
> > > If the midlevel restricts your device queue to 1 then
> > > that is a problem with either
> > > - the mid-level
> > > - or your driver's callback function provided to
> > > calculate queue depth.
> >
> > The driver source did not change (famous last words) when
> > I noticed the choke down. Sooo, I guess that means
> > a problem introduced in the scsi mid-level? @2.3.43?
> > That's my big concern and why I posted to the linux-scsi list;
> > it's not nice to be cruising along and have things like this
> > change this underneath, but hey, that's linux life. :-)
> >
> > How are you measuring the tagged queueing? From underneath
> > (bus analyser), inside your driver or from above (e.g. dd)?
> >
> > Yes. :-) I noticed this inside the driver. Don't have FC analyzer
> > on there, but also measured / confirmed this inside the HAB
> > firmware processor(s) using ARM Multi-ICE debugger...
> >
> > BTW: I'm pretty (99%) sure there's no problem with my 2.3.43,
> > 2.3.44, 2.3.45+ikd, nor 2.3.45 stock kernel source trees.
> > I even dropped back to stock 2.3.45 kernel to make sure
> > my feeble hacks patching in 2.3.40-ikd2 weren't the culprit.
> >
> > Thanks,
> > -SteveR
> >
> > > -----Original Message-----
> > > From: Douglas Gilbert [SMTP:dgilbert@724.com]
> > > Sent: Tuesday, February 15, 2000 2:16 PM
> > > To: 'Ralston, Steve'; Douglas Gilbert
> > > Cc: 'eric@andante.org'
> > > Subject: RE: scsi queue depth problem
> > >
> > > Steve,
> > > So it works on 2.3.42 and is restricted to a queue length
> > > of 1 on 2.3.45 I gather. Perhaps you could try again to
> > > do what I suggested on 2.3.45 . If the midlevel restricts
> > > your device queue to 1 then that is a problem with either
> > > - the mid-level
> > > - or your driver's callback function provided to
> > > calculate queue depth.
> > >
> > > How are you measuring the tagged queueing? From underneath
> > > (bus analyser), inside your driver or from above (e.g. dd)?
> > > In the unlikely event you are using dd then I have a useful
> > > utility called sgp_dd that uses posix worker threads (up to
> > > 16) to push multiple scsi commands down a mid-level queue.
> > > While this is happening it can be observed with
> > > "cd /proc/scsi/sg/debug; cat debug"
> > > (if you are using the correct version of sg :-) ).
> > > You'll find this utility at http://www.torque.net/sg
> > >
> > >
> > > Doug Gilbert
> > >
> > > > -----Original Message-----
> > > > From: Ralston, Steve [mailto:steve.ralston@lsil.com]
> > > > Sent: Tuesday, February 15, 2000 12:35 PM
> > > > To: 'Douglas Gilbert'
> > > > Cc: 'eric@andante.org'
> > > > Subject: RE: scsi queue depth problem
> > > >
> > > >
> > > > Sorry again. I'd already stepped back to linux-2.3.42 kernel
> > > > when I tried loading sg. I see the CONFIG_PROC_FS stuff
> > > > didn't show up till 2.3.43.
> > > >
> > > > Not sure where to look next...
> > > >
> > > > Thanks,
> > > > -SteveR
> > > >
> > > > > -----Original Message-----
> > > > > From: Douglas Gilbert [SMTP:dgilbert@724.com]
> > > > > Sent: Tuesday, February 15, 2000 11:20 AM
> > > > > To: 'steve.ralston@lsil.com'
> > > > > Cc: 'eric@andante.org'
> > > > > Subject: RE: scsi queue depth problem
> > > > >
> > > > > Steve,
> > > > > You wrote (on the linux-scsi newsgroup):
> > > > > > > Perhaps you could load the sg driver and try:
> > > > > > > $ cd /proc/scsi/sg
> > > > > > > $ cat device_hdr devices
> > > > > > > $ cat host_hdr hosts
> > > > > > Sorry, I've tried loading the sg driver, but it is not
> > > > yielding ANY
> > > > > > /proc/scsi entries, even though I definitely have CONFIG_PROC_FS
> > > > > > set in my kernel/module builds. (I don't even see
> CONFIG_PROC_FS
> > > > > > anywhere in drivers/scsi/sg.c)
> > > > >
> > > > > It seems as though your kernel source tree has problems.
> > > > > According to a kernel source browser such as:
> > > > > http://zaphod.redwave.net/linux/kernel-2.3/
> > > > >
> > > > > CONFIG_PROC_FS appears 7 times in drivers/scsi/sg.c in
> > > > > 2.3.45 . Perhaps you should download the complete
> > > > > linux-2.3.45 source and retest your queuing problem.
> > > > >
> > > > > Doug Gilbert
> > > >
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.rutgers.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
