Re: [PATCH + RFC] Beginning of some updates to scsi mid layer

[Doug Ledford <dledford@redhat.com>]

On Wed, Jun 19, 2002 at 01:44:36PM -0400, Pete Zaitcev wrote:
> >   So, when Justin Gibbs' driver allocates a queue depth of 253 
> > commands on drive X, then finds out that drive X has a hard limit of 64, 
> > then we aren't continuing to waste 189 commands worth of allocated kernel 
> > memory that can never be effectively used.
> 
> > +		  diff = p->dev_lun_queue_depth[tindex] -
> > +			 p->dev_active_cmds[tindex];
> > +		  p->dev_lun_queue_depth[tindex] -= diff;
> 
> I think this is not enough, or backwards. We hit a situation with
> EMC when attaching hundreds of disks depleted atomic memory with
> queue request arrays before swapper had a chance to replenish it.
> I would much appreciate if the initial allocation was concervative,
> if low performing, and was adjusted upwards at slave_attach time.

This is actually from the runtime code, part of my interrupt handler.  It 
notices that we might get a lot of QUEUE_FULLs from a device all at the 
same queue depth, and in that case it reduces the queue depth to the new 
depth.  So, in short, it's not backwards, it's actually taking the depth 
down based upon solid feedback from the drive.

> For 2.5 I would appreciate if we made some SCSI allocations non-atomic.
> The probe time things better be GFP_KERNEL.

Noted, I'll change that soon.  As long as we have at least 1 command 
block, then the other allocations can be at our leisure since the change 
to scsi_release_command() will attempt to allocate 1 command block per 
completed command until they catch up to the intended queue depth.  And, 
since that isn't done from an interrupt, all make it GFP_KERNEL as well 
and if we fail, then we simply wait and do the allocation later.

Allocations on the aic7xxx_old driver are a different thing.  Don't pay 
too much attention to them.  This work I'm doing here has pointed out to 
me that the tagged queue handling in the driver is totally busted in 
regards to multi-lun disk devices.  I would actually have to do a rather 
large overhaul to get it right, and that's not on the plate until I've 
got some of this other stuff out of the way.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606