Ideas for a new io scheduler for desktop

Ideas for a new io scheduler for desktop

[Pedro Larroy]

Hi

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.

Regards.
-- 
Pedro Larroy Tovar | Linux & Network consultant |  pedro%larroy.com 
Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/
	* Las patentes de programación son nocivas para la innovación * 
				http://proinnova.hispalinux.es/

Re: Ideas for a new io scheduler for desktop

[Robert Love]

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

Re: Ideas for a new io scheduler for desktop

[Pedro Larroy]

On Tue, Nov 09, 2004 at 08:50:19PM -0500, 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.
> > 
> > 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
> 

Yes, I use them in all of my boxes.

Regards.
-- 
Pedro Larroy Tovar | Linux & Network consultant |  pedro%larroy.com 
Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/
	* Las patentes de programación son nocivas para la innovación * 
				http://proinnova.hispalinux.es/

Re: Ideas for a new io scheduler for desktop

[Prakash K. Cheemplavam]

[-- 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 --]