Re: [PATCH] O13int for interactivity

[Rob Landley <rob@landley.net>]

On Tuesday 05 August 2003 03:26, Con Kolivas wrote:
> On Tue, 5 Aug 2003 16:03, Andrew Morton wrote:
> > We do prefer that TASK_UNINTERRUPTIBLE processes are woken promptly so
> > they can submit more IO and go back to sleep.  Remember that we are
> > artificially leaving the disk head idle in the expectation that the task
> > will submit more I/O.  It's pretty sad if the CPU scheduler leaves the
> > anticipated task in the doldrums for five milliseconds.
>
> Indeed that has been on my mind. This change doesn't affect how long it
> takes to wake up. It simply prevents tasks from getting full interactive
> status during the period they are doing unint. sleep.
>
> > Very early on in AS development I was playing with adding "extra boost"
> > to the anticipated-upon task, but it did appear that the stock scheduler
> > was sufficiently doing the right thing anyway.
>
> Con

It seems that there's a special case, where a task that was blocked on a read 
(either from a file or from swap) wants to be scheduled immediately, but with 
a really short timeslice.  I.E. give it the ability to submit another read 
and block on it immediately, but if a single jiffy goes by and it hasn't done 
it, it should go away.

This has nothing to do with the normal priority levels or being considered 
interactive or not.  As I said, a special case.  IO_UNBLOCKED_FLAG or some 
such.  Maybe unnecessary...

(Once again, the percentage of CPU time to devote to a task and the immediacy 
of scheduling that task are in opposition.  The "priority" abstraction is a 
bit too simple at times...)

Rob