Subject: Re: I/O priorities
To: Gary Thorpe <gat7634@hotmail.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 06/21/2002 11:13:32
In message <F118uYDlrjbudzxxfYX000261fe@hotmail.com>"Gary Thorpe" writes
>>From: Jonathan Stone <jonathan@DSG.Stanford.EDU>

>Here is my oversimplistic analysis:

[1.5.2 has fixed buffer cache, which puts an upper bound on how much
sustained damage an I/O hungry process can do; 1.6 with UBC allows
more buffering which lets us get into situations where `hogs' do
sustained damage to real-time tasks]

It's not so over-simplistic. I think the main thing being overlooked
is that Manuel's case cares about *latency*, not I/O bandwidth.

Some of the proposed solutions seem to miss that. They'd fix the
problem for a small burst from a high-priority burst, but not fix the
latency in serving that first request. It's when the low-priority guy
is doing a pagein for interactive feedback (X) that Manuel cites, and
there, it's latency that is the real killer.