From: Mike Anderson <mike.anderson@us.ibm.com>
To: Jens Axboe <axboe@suse.de>
Cc: Dipankar Sarma <dipankar@sequent.com>, linux-kernel@vger.kernel.org
Subject: Re: io_request_lock patch?
Date: Wed, 11 Jul 2001 14:05:54 -0700 [thread overview]
Message-ID: <20010711140554.A27815@us.ibm.com> (raw)
In-Reply-To: <20010710172545.A8185@in.ibm.com> <20010710160512.A25632@us.ibm.com> <20010711142311.B9220@in.ibm.com> <20010711090257.B27097@us.ibm.com> <20010711212022.H712@suse.de> <20010712014328.A14094@in.ibm.com> <20010711221719.P712@suse.de>
In-Reply-To: <20010711221719.P712@suse.de>; from axboe@suse.de on Wed, Jul 11, 2001 at 10:17:19PM +0200
Jens Axboe [axboe@suse.de] wrote:
> On Thu, Jul 12 2001, Dipankar Sarma wrote:
> > On Wed, Jul 11, 2001 at 09:20:22PM +0200, Jens Axboe wrote:
> > > True. In theory it would be possible to do request slot stealing from
> > > idle queues, in fact it's doable without adding any additional overhead
> > > to struct request. I did discuss this with [someone, forgot who] last
> > > year, when the per-queue slots where introduced.
> > >
> > > I'm not sure I want to do this though. If you have lots of disks, then
> > > yes there will be some wastage if they are idle. IMO that's ok. What's
> > > not ok and what I do want to fix is that slower devices get just as many
> > > slots as a 15K disk for instance. For, say, floppy or CDROM devices we
> > > really don't need to waste that much RAM. This will change for 2.5, not
> > > before.
> >
> > Unless there is some serious evidence substantiating the need for
> > stealing request slots from other devices to avoid starvation, it
> > makes sense to avoid it and go for a simpler scheme. I suspect that device
> > type based slot allocation should just suffice.
>
> My point exactly. And typically, if you have lots of queues you have
> lots of RAM. A standard 128meg desktop machine does not waste a whole
> lot.
I would vote for the simpler approach of slots. :-).
>
> --
> Jens Axboe
--
Michael Anderson
mike.anderson@us.ibm.com
next prev parent reply other threads:[~2001-07-11 21:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-10 11:55 io_request_lock patch? Dipankar Sarma
2001-07-10 23:05 ` Mike Anderson
2001-07-11 7:15 ` Jens Axboe
2001-07-11 8:53 ` Dipankar Sarma
2001-07-11 8:53 ` Jens Axboe
2001-07-11 14:02 ` Dipankar Sarma
2001-07-11 14:01 ` Jens Axboe
2001-07-11 14:55 ` Dipankar Sarma
2001-07-11 19:16 ` Jens Axboe
2001-07-11 16:02 ` Mike Anderson
2001-07-11 19:20 ` Jens Axboe
2001-07-11 20:13 ` Dipankar Sarma
2001-07-11 20:17 ` Jens Axboe
2001-07-11 21:05 ` Mike Anderson [this message]
2001-07-11 7:19 ` Jens Axboe
2001-07-11 8:39 ` Dipankar Sarma
2001-07-11 8:47 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2001-07-09 19:39 Jonathan Lahr
2001-07-09 19:44 ` Jens Axboe
2001-07-10 19:49 ` Jonathan Lahr
2001-07-10 20:09 ` Eric Youngdale
2001-07-11 8:05 ` Jens Axboe
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=20010711140554.A27815@us.ibm.com \
--to=mike.anderson@us.ibm.com \
--cc=axboe@suse.de \
--cc=dipankar@sequent.com \
--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 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.