Re: Problem with aacraid driver in 2.5.63-bk-latest

Douglas Gilbert <[email protected]>
Newsgroups gmane.linux.scsi,gmane.linux.kernel,gmane.linux.drivers.aacraid.devel
Message-ID <[email protected]>
Alan Cox wrote:
> On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
> 
>>         /*
>>          * Limit max queue depth on a single lun to 256 for now.  Remember,
>>          * we allocate a struct scsi_command for each of these and keep it
>>          * around forever.  Too deep of a depth just wastes memory.
>>          */
>>         if(tags > 256)
>>                 return;
>>....
> 
> 
> I can see the memory consideration. However the thing can really handle big
> queues well. Possibly we should be setting the queue to 512 / somefunction(volumes)
> though to avoid the worst case overcommit here

The situation is different between 2.4 and 2.5 ...

In 2.4 the per device queue_depth is an unsigned char
and that number of scsi_cmnd instances are pre-allocated
in the scsi_build_commandblocks() function. So the worst
case number of scsi_cmnd instances for all scsi devices
is always available (at the expense of [wasted] ram).

In 2.5 queue_depth is an unsigned short and a slab
allocator called "scsi_cmd_cache" is used as required.
There is some throttle logic (or at least it has been
talked about) to make sure one scsi_cmnd instance per
scsi device will always be available.

I think that comment (probably by Doug Ledford) refers
to the 2.5 series before the slab allocator was
introduced.

Doug Gilbert



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.