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/
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
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/
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