public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Anderson <andmike@us.ibm.com>
To: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: queue_nr_requests needs to be selective
Date: Fri, 1 Mar 2002 16:51:04 -0800	[thread overview]
Message-ID: <20020301165104.C6778@beaverton.ibm.com> (raw)
In-Reply-To: <20020301132254.A11528@vger.timpanogas.org>
In-Reply-To: <20020301132254.A11528@vger.timpanogas.org>; from jmerkey@vger.timpanogas.org on Fri, Mar 01, 2002 at 01:22:54PM -0700

Jeff V. Merkey [jmerkey@vger.timpanogas.org] wrote:
> 
> ..snip..
>
> What is really needed here is to allow queue_nr_requests to be 
> configurable on a per adapter/device basis for these high end 
> raid cards like 3Ware since in a RAID 0 configuration, 8 drives
> are in essence a terabyte (1.3 terrabytes in our configuration) 
> and each adapter is showing up as a 1.3 TB device.  64/128
> requests are simply not enough to get the full spectrum of 
> performance atainable with these cards.
> 
Not having direct experience on this card it appears that increasing the
queue_nr_requests number will not allow you to have more ios in flight.

Unless I am reading the driver wrong you will be limited to
TW_MAX_CMDS_PER_LUN (15). This value is used by scsi_build_commandblocks
to allocate scsi commands for your scsi_device. This driver does not provide
a select_queue_depths function which allows for increase to the default
template value. 

Could it be that the experimentation of increasing this number has
allowed for better merging.

-Mike
-- 
Michael Anderson
andmike@us.ibm.com


  parent reply	other threads:[~2002-03-02  2:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-01 20:22 queue_nr_requests needs to be selective Jeff V. Merkey
2002-03-01 20:43 ` Andrew Morton
2002-03-01 21:03   ` Alan Cox
2002-03-01 23:22     ` Jeff V. Merkey
2002-03-01 23:20   ` Jeff V. Merkey
2002-03-01 23:23     ` Andrew Morton
2002-03-02  0:27       ` Jeff V. Merkey
2002-03-02  0:49         ` Andrew Morton
2002-03-02  2:16           ` Jeff V. Merkey
2002-03-02  3:50             ` Andrew Morton
2002-03-02  4:34               ` Jeff V. Merkey
2002-03-02  7:33               ` Jeff V. Merkey
2002-03-02  9:10               ` Jens Axboe
2002-03-02  9:22                 ` Andrew Morton
2002-03-04  9:09                   ` Jens Axboe
2002-03-02  0:51 ` Mike Anderson [this message]
2002-03-02  4:39   ` Jeff V. Merkey
2002-03-02  5:59     ` Jeff V. Merkey
2002-03-02  6:01       ` Jeff V. Merkey
2002-03-02  6:16         ` Jeff V. Merkey
2002-03-04  7:16       ` Mike Anderson
2002-03-04 17:39         ` Jeff V. Merkey

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=20020301165104.C6778@beaverton.ibm.com \
    --to=andmike@us.ibm.com \
    --cc=jmerkey@vger.timpanogas.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox