From: "Prakash K. Cheemplavam" <prakashkc@gmx.de>
To: Robert Love <rml@novell.com>
Cc: Pedro Larroy <piotr@larroy.com>, linux-kernel@vger.kernel.org
Subject: Re: Ideas for a new io scheduler for desktop
Date: Wed, 10 Nov 2004 12:22:14 +0100 [thread overview]
Message-ID: <4191F9E6.9010709@gmx.de> (raw)
In-Reply-To: <1100051419.18601.105.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Robert Love wrote:
> 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.
[snip]
>
> 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.
BTW, I saw the same problem, though not with reading, but with writing
to disk. See thread (well nobody answered to it yet):
[2.6.10-rc1 and prev] System unuseable while writing to disk
It really takes away the fun... :(
Prakash
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-11-10 11:22 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
2004-11-10 2:07 ` Pedro Larroy
2004-11-10 11:22 ` Prakash K. Cheemplavam [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=4191F9E6.9010709@gmx.de \
--to=prakashkc@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=piotr@larroy.com \
--cc=rml@novell.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.