RE: 16 commands per lun limitation bug?

[James Bottomley <James.Bottomley@suse.de>]

On Wed, 2010-02-10 at 22:19 +0000, Miller, Mike (OS Dev) wrote:
> 
> > -----Original Message-----
> > From: James Bottomley [mailto:James.Bottomley@suse.de] 
> > Sent: Wednesday, February 10, 2010 3:59 PM
> > To: scameron@beardog.cce.hp.com
> > Cc: linux-scsi@vger.kernel.org; Miller, Mike (OS Dev)
> > Subject: Re: 16 commands per lun limitation bug?
> > 
> > On Wed, 2010-02-10 at 14:19 -0600, scameron@beardog.cce.hp.com wrote:
> > > We have seen the amount of commands per lun that are sent 
> > to low level 
> > > scsi driver limited to 16 commands per lun, (seemingly 
> > artificially, 
> > > well below our can_queue and cmd_per_lun limits of 1020)
> > > 
> > > 2.6.29 does not exhibit this bad behavior.
> > > 2.6.30, 2.6.31, 2.6.32 (2.6.32.1 through 2.6.32.8) do 
> > exhibit this bad 
> > > behavior
> > > 2.6.31-rc1 does not exhibit this bad behavior
> > 
> > I can't think of any reason for this.  Best guess at the fix 
> > would be the new queue full ramp up ramp down code, but no 
> > clue as to what the problem is ... no other drivers seem to 
> > have noticed the performance problems this would likely cause 
> > ... and 2.6.32 is becoming the standard enterprise kernel.
> > 
> James,
> I'm not sure there's much hardware out there that's capable of queuing
> up so many commands without choking the disks. I _think_ in most cases
> if you queue up say 64 commands on a single scsi disk that's just too
> much. But with Smart Array we can queue up to 1024 commands (on most
> controllers) and those are then distributed across all the drives in
> the array(s). IOW, we're thinking not many people would have noticed
> such a change. Hope this makes sense.

Fibre drivers to FC arrays would regard a depth of 16 as "fiddling small
change" to quote hitchhikers.  If any of the FC drivers got limited in
this regard, we'll see substantial enterprise performance drops ...
which I haven't actually heard about yet.

James