On Fri, Jun 21, 2002 at 10:51:24AM -0700, Jonathan Stone wrote:
> 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.''

Wow.  No one's ever called me "Master" before. :)

> 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 largest `batch' quantum. 
>
> Here's the hard part: if a batch job is running (large CPU-quantum, or
> the elevator algorithm is part way 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.

Master Stone, that sounds like "elevate the priority" reworded as
"service the [high-priority] queue."

I think we're on the same page, but describing different aspects of it.
The (b) is described in the previous post as a system-blocking event,
which translated out to the user's POV is a real-time critical event.

If I read you right, you're suggesting a low-priority "batch" queue and
a high-priority "interactive" queue.  I'm describing what could be
classified as a batch process starving out what could be classified as
an interactive process without calling them "batch" or "interactive" and
claiming we need to "elevate the priority of [the interactive event]."

Both of us suggest a multiple queue approach.

The quantum... I've of two minds regarding it.  

On the one hand, I'd like to see higher priority events serviced
immediately.  This would provide better than soft-realtime, not quite
hard-realtime responsiveness.  The downside being that too many high
priority events would trash overall system performance.

On the other hand, requiring that the low priority queue run for a
certain quantum before it's interruptible.  This would soften the
realtime service, while maintaining good overall system performance.  And
the quantum only really comes into play when the high-priority events
have a higher frequency than the quantum.

Ok.  I like the quantum.

jf
-- 
John Franklin
franklin@elfie.org
ICBM: 35°43'56"N 78°53'27"W