[lkml]   [2003]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] O13int for interactivity
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...)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.163 / U:2.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site