All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Dipankar Sarma <dipankar@sequent.com>
Cc: mike.anderson@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: io_request_lock patch?
Date: Wed, 11 Jul 2001 22:17:19 +0200	[thread overview]
Message-ID: <20010711221719.P712@suse.de> (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>
In-Reply-To: <20010712014328.A14094@in.ibm.com>

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.

-- 
Jens Axboe


  reply	other threads:[~2001-07-11 20:18 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 [this message]
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=20010711221719.P712@suse.de \
    --to=axboe@suse.de \
    --cc=dipankar@sequent.com \
    --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.