[parisc-linux] Re: 53c700: tagged queueing problem confirmed

[parisc-linux] Re: 53c700: tagged queueing problem confirmed

[Daniel Engstrom]

On 2001.10.22 02:34 James Bottomley wrote:
> 5116@telia.com said:
> > I have investigated this some more and I have come to the conclustion
> > that you are quite right. I disabled tagged queueing in the drivber
> > and it instantly bacame stable.
> 
> > Do you have any idea on how to proceed debugging this? 
> 
> Well here's my theory:
> 
> There are a number of reports with tag command queueing problems
> associated with these drives.  In particular, one for freebsd said 
> that the aic7xxx driver was reporting data overruns with TCQ enabled 
> on Quantum Fireballs.
Ok.

I have used these drives with i386 Linux without problems with both the
aix7xxx driver and the sym53c8xx driver. Both these drivers use a default of max
8 tags per lun, so I chnaged the value in your driver and it works.
So, maybe 8 tags per lun is the conservative default here ?

/Daneil 
-- 

[parisc-linux] Re: 53c700: tagged queueing problem confirmed

[James Bottomley]

5116@telia.com said:
> I have used these drives with i386 Linux without problems with both
> the aix7xxx driver and the sym53c8xx driver. Both these drivers use a
> default of max 8 tags per lun, so I chnaged the value in your driver
> and it works. So, maybe 8 tags per lun is the conservative default
> here ? 

That's not unreasonable.  You're going to run into problems with the new 
aic7xxx driver, though, which has a default of 253 tags.

Usually you want larger numbers of tags to allow multiple active I/Os and give 
the device the most freedom to order them efficiently.  However, in linux we 
have the elevator to consider as well:  The more tags, the less time the I/Os 
spend in the elevator queue and the less chance of coalescing adjacent I/O.  
For any given workload, there's probably an optimal tag number and I bet they 
cluster around some value for a variety of workloads, but I've no idea what it 
is.

I'd still be wary of allowing tags on this drive.  The firmware clearly has a 
point beyond which it goes haywire and you don't really know where that is.  
It could be that reducing the max tags to 8 makes this unlikely but not 
impossible, so you may still end up with insidious data corruption 
possibilities.

James

Re: [parisc-linux] Re: 53c700: tagged queueing problem confirmed

[Grant Grundler]

James Bottomley wrote:
> That's not unreasonable.  You're going to run into problems with the new 
> aic7xxx driver, though, which has a default of 253 tags.
> 
> Usually you want larger numbers of tags to allow multiple active I/Os
> and give the device the most freedom to order them efficiently.

Hmm...not really. Maybe for DOS or other really stupid OS's.

> However, in linux we have the elevator to consider as well:  The
> more tags, the less time the I/Os spend in the elevator queue and
> the less chance of coalescing adjacent I/O.  

That's right...coalescing and seek times need to be considered.
WCE bit (that I described before) also affects how long
IO are on the disk sort queue. With WCE enabled, setting the
max number of tags to 2 (or so) works very nicely.

I'm told Linux's disk sort elevator isn't very good about starvation.
ie IO's can get "prempted" for a long time because the IO
is destined for a currently "out of favor" geography on the disk.

One more consideration unique to multi-initiator SCSI clusters:
(Ie several hosts share devices on one SCSI bus)
The total number of outstanding IO can't exceed what the disk
is capable of handling or we end up wasting bandwidth to
requeue rejected IO's (BUSY msg or something like that).

> For any given workload, there's probably an optimal tag number and I bet
> they cluster around some value for a variety of workloads, but I've no
> idea what it is.

8 tags seems to be a pretty good trade off between on-disk optimizations
and OS trade-offs for database apps. At least that was true a few years
ago.

> I'd still be wary of allowing tags on this drive.  The firmware clearly has a
> point beyond which it goes haywire and you don't really know where that is.  
> It could be that reducing the max tags to 8 makes this unlikely but not 
> impossible, so you may still end up with insidious data corruption 
> possibilities.

Check with the vendor to see if the firmware is upgradeable.
Odds are if someone like HP or Sun is OEM'ing the disk, bugs
in the firmware have been found and fixed in later versions.

grant