public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Love <rml@novell.com>
To: Pedro Larroy <piotr@larroy.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Ideas for a new io scheduler for desktop
Date: Tue, 09 Nov 2004 20:50:19 -0500	[thread overview]
Message-ID: <1100051419.18601.105.camel@localhost> (raw)
In-Reply-To: <20041110013235.GA13691@larroy.com>

On Wed, 2004-11-10 at 02:32 +0100, Pedro Larroy wrote:

> I think that a new io-scheduler that gave priority to bursty access to
> block devices would be interesting for desktop and workstation use, and
> even for some servers.
> 
> I'm often waiting for graphical aplications, vim, mutt, and almost every
> program to which I have to interact with because they are blocked
> waiting for just a few blocks of IO that won't get served fast just
> because there's a single process hog that's provoking that high latency.
> 
> In network terminology the disk just feel like a network interface without QoS, 
> service time just goes up insanely with just one client in the queue.
> 
> Although much care should be taken in designing this algorithm to
> prevent unfairness, I believe there's room for improvement in this area.
> 
> I'd like to read about your opinions.

What you are seeing is the affect of read requests being synchronous,
and thus the pain of read latency, and write requests to one part of the
disk starving other requests.

Have you tried the new 2.6 I/O schedulers?  They should prevent this
problem.

If you are using 2.6, then your problem might not lie with the I/O
scheduler.  Read request deadlines are very low in both the deadline and
anticipatory I/O scheduler.

	Robert Love



  reply	other threads:[~2004-11-10  1:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-10  1:32 Ideas for a new io scheduler for desktop Pedro Larroy
2004-11-10  1:50 ` Robert Love [this message]
2004-11-10  2:07   ` Pedro Larroy
2004-11-10 11:22   ` Prakash K. Cheemplavam

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=1100051419.18601.105.camel@localhost \
    --to=rml@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piotr@larroy.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