All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Mark Haverkamp <markh@osdl.org>,
	Christoffer Hall-Frederiksen <hall@jiffies.dk>,
	linux-scsi@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux aacraid devel <linux-aacraid-devel@dell.com>,
	dledford@redhat.com
Subject: Re: Problem with aacraid driver in 2.5.63-bk-latest
Date: Thu, 13 Mar 2003 11:31:13 +1000	[thread overview]
Message-ID: <3E6FDF61.8060708@torque.net> (raw)
In-Reply-To: 1047517604.23902.39.camel@irongate.swansea.linux.org.uk

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




  parent reply	other threads:[~2003-03-13  1:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-28 13:30 Problem with aacraid driver in 2.5.63-bk-latest Christoffer Hall-Frederiksen
2003-03-12 23:06 ` Mark Haverkamp
2003-03-13  0:18   ` Alan Cox
2003-03-12 23:55     ` Douglas Gilbert
2003-03-13  1:06       ` Alan Cox
2003-03-13  0:50         ` Mike Anderson
2003-03-13 23:13           ` Mark Haverkamp
2003-03-14  7:05           ` Denis Vlasenko
2003-03-14 10:18             ` Mike Anderson
2003-03-13  1:31         ` Douglas Gilbert [this message]
2003-03-13 23:27           ` Doug Ledford
2003-03-13 15:42         ` Mark Haverkamp
2003-03-13 23:17           ` Doug Ledford
2003-03-13 23:22             ` Mark Haverkamp
2003-03-13 23:25               ` Doug Ledford
2003-03-14 14:57                 ` Alan Cox
2003-03-14 15:34                   ` Mark Haverkamp
2003-03-14 16:48                     ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-03-03 10:05 Christoffer Hall-Frederiksen
2003-03-03 13:40 ` Alan Cox
2003-03-03 14:46   ` Christoffer Hall-Frederiksen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E6FDF61.8060708@torque.net \
    --to=dougg@torque.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dledford@redhat.com \
    --cc=hall@jiffies.dk \
    --cc=linux-aacraid-devel@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=markh@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.