From: Jens Axboe <axboe@suse.de>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: Patrick Mansfield <patmans@us.ibm.com>,
Christoph Hellwig <hch@infradead.org>,
lkml@lpbproductions.com, Timothy Miller <miller@techsource.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: 3ware queue depth [was: Re: HIGHMEM4G config for 1GB RAM on desktop?]
Date: Sat, 4 Sep 2004 12:10:08 +0200 [thread overview]
Message-ID: <20040904101008.GC1610@suse.de> (raw)
In-Reply-To: <1094077436l.22433l.3l@drinkel.cistron.nl>
On Wed, Sep 01 2004, Miquel van Smoorenburg wrote:
> On Wed, 01 Sep 2004 21:43:25, Patrick Mansfield wrote:
> >On Wed, Sep 01, 2004 at 11:08:39AM +0000, Miquel van Smoorenburg wrote:
> >
> >> + /* make sure blockdev queue depth is at least 2 * scsi depth */
> >> + if (SDptr->request_queue->nr_requests < 2 * max_cmds)
> >> + SDptr->request_queue->nr_requests = 2 * max_cmds;
> >
> >Why would you want nr_requests different (and larger) only for this
> >driver?
>
> Because for the Linux I/O scheduler to work, nr_requests needs to
> be at least twice as big as the scsi queue depth.
Well, basically if you want to have a chance to do any io scheduling
anywhere, you need to have more than 1 request to play with really. And
if the drive is swallowing all your requests all the time, you are
screwed. I do think the best option (as some people mentioned in this
thread) is to limit the 3ware queue depth, not increase the io scheduler
depth. At least for most of the current io schedulers, this will kill
your latency quite a bit.
> >Is modifying nr_requests allowed?
>
> Well we need to do the same things that ll_rw_blk::queue_requests_store()
> does, only we don't need to worry about locking or existing queue
> contents since the queue has been instantiated but the scsi device
> is not active yet.
>
> I do notice now however, that between 2.6.4 and 2.6.9-rc1
> blk_queue_congestion_threshold() has been added which we should
> probably call after adjusting nr_requests. Unfortunately it's
> a static function in ll_rw_blk.c ..
>
> Perhaps we should export the functionality of queue_requests_store()
> as, say, queue_adjust_nr_requests() (like scsi_adjust_queue_depth) ?
> Jens ?
Yes, if you want to do this, we need to export a function to do it that
takes care of updating the block layer congestion (etc) data.
> Anyway, for now, perhaps the mucking with nr_requests should be
> taken out and a change like the above should be sent to the
> people at 3ware.
Indeed.
> I'll submit the sysfs code for inclusion in -mm and the nr_requests
> stuff to 3ware.
Great!
--
Jens Axboe
prev parent reply other threads:[~2004-09-04 10:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-02 21:02 HIGHMEM4G config for 1GB RAM on desktop? Steve Snyder
2004-08-02 21:32 ` Bart Alewijnse
2004-08-02 22:05 ` Barry K. Nathan
2004-08-03 13:30 ` Jens Axboe
2004-08-03 14:13 ` Prakash K. Cheemplavam
2004-08-03 14:29 ` Con Kolivas
2004-08-04 6:06 ` Jens Axboe
2004-08-04 11:14 ` Eric Bambach
2004-08-04 13:07 ` Jens Axboe
2004-08-04 19:06 ` Andrew Morton
2004-08-04 19:21 ` Marc-Christian Petersen
2004-08-04 19:30 ` Martin J. Bligh
2004-08-04 19:51 ` Andrew Morton
2004-08-04 20:09 ` Martin J. Bligh
2004-08-04 20:09 ` Roland Dreier
2004-08-04 20:13 ` Martin J. Bligh
2004-08-12 0:53 ` Timothy Miller
2004-08-30 18:06 ` Timothy Miller
2004-08-30 17:49 ` Miquel van Smoorenburg
2004-08-31 22:46 ` Timothy Miller
2004-09-01 7:52 ` Miquel van Smoorenburg
2004-09-01 9:38 ` Matt Heler
[not found] ` <1094030083l.3189l.2l@traveler>
[not found] ` <1094030194l.3189l.3l@traveler>
[not found] ` <200409010233.31643.lkml@lpbproductions.com>
2004-09-01 9:58 ` 3ware queue depth [was: Re: HIGHMEM4G config for 1GB RAM on desktop?] Miquel van Smoorenburg
2004-09-01 10:09 ` Christoph Hellwig
2004-09-01 11:08 ` Miquel van Smoorenburg
2004-09-01 11:43 ` Christoph Hellwig
2004-09-01 19:43 ` Patrick Mansfield
2004-09-01 22:23 ` Miquel van Smoorenburg
2004-09-04 10:10 ` Jens Axboe [this message]
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=20040904101008.GC1610@suse.de \
--to=axboe@suse.de \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkml@lpbproductions.com \
--cc=miller@techsource.com \
--cc=miquels@cistron.nl \
--cc=patmans@us.ibm.com \
/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