From: Dipankar Sarma <dipankar@sequent.com>
To: Jens Axboe <axboe@suse.de>
Cc: mike.anderson@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: io_request_lock patch?
Date: Thu, 12 Jul 2001 01:43:28 +0530 [thread overview]
Message-ID: <20010712014328.A14094@in.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>
In-Reply-To: <20010711212022.H712@suse.de>; from axboe@suse.de on Wed, Jul 11, 2001 at 09:20:22PM +0200
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.
Thanks
Dipankar
--
Dipankar Sarma <dipankar@sequent.com> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
next prev parent reply other threads:[~2001-07-11 20:09 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 [this message]
2001-07-11 20:17 ` Jens Axboe
2001-07-11 21:05 ` Mike Anderson
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=20010712014328.A14094@in.ibm.com \
--to=dipankar@sequent.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.anderson@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 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.