In message <20020621140052.GC1856@deathmitten.example.org>John Franklin writes
>On Fri, Jun 21, 2002 at 03:31:19PM +0200, Olaf Seibert wrote:
[...]

>The solution we seek is to elevate the priority of (b) so the system
>isn't blocked.

Nope. ``circumstances force me to disagree with you, Master.''

Succinctly, we need to reduce the granularity of I/O scheduling: to
reduce the *latency* in servicing the low-rate, but real-time jobs
like Manuel's xterm.

An analogy with with CPU scheduling may help: in essence, our quantum
is far, far too large.  A more accurate analogy would take the cost of
disk movement into account. Again, by analogy with CPU scheduling: if
there are any "interactive"/soft-realttime processes waiting for the
CPU, use an `interactive' quantum. If there are only batch jobs, use
the larget `batch' quantum. 

Here's the hard part: if a batch job is running (large CPU-quantum, or
the elevator algorithm is partway through a very large sorted list) we
need a way to switch to the `small' quantum part-way through the
*current* cycle, not the *next* cycle.

IOW, juggle most of the current (not pending) elevator-sorted queue
back into the `pending' queue, sort any high-priority requests into a
new, much smaller queue, and service that (much shorter) disk queue.

... just out of curiosity, how does FreeBSD handle this problem?