lkml.org 
[lkml]   [2003]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] O12.2int for interactivity
Date
On Thu, 14 Aug 2003 17:01, William Lee Irwin III wrote:
> On Thu, 14 Aug 2003 16:09, William Lee Irwin III wrote:
> >> "scale" on which scheduling events should happen, and as tasks become
> >> more cpu-bound, they have longer timeslices, so that two cpu-bound
> >> tasks of identical priority will RR very slowly and have reduced
> >> context switch overhead, but are near infinitely preemptible by more
> >> interactive or short-running tasks.
>
> On Thu, Aug 14, 2003 at 04:59:33PM +1000, Con Kolivas wrote:
> > Actually the timeslice handed out is purely dependent on the static
> > priority, not the priority it is elevated or demoted to by the
> > interactivity estimator. However lower priority tasks (cpu bound ones if
> > the estimator has worked correctly) will always be preempted by higher
> > priority tasks (interactive ones) whenever they wake up.
>
> So it is; the above commentary was rather meant to suggest that the
> lengthening of timeslices in conventional arrangements did not penalize
> interactive tasks, not to imply that priority preemption was not done
> at all in the current scheduler.

While you're on the subject can I just clarify some details about the arrays.
If a task doesn't use up it's full timeslice and goes back to sleep, it
starts gaining bonus points which elevate it's interactivity in the eyes of
the scheduler. When it wakes up again, it will always go onto the active
array. While running, it's bonus points are being burnt off on a time basis.
If it then uses up it's timeslice, depending on whether it is above or below
a cuttoff (the delta) based on the level of interactivity of the task, the
scheduler will decide to put it on the end of the active array again, or
expire it. Thus tasks that never sleep are always below the interactive delta
so each time they use up their timeslice they go onto the expired array.
Tasks with enough bonus points can go back onto the active array if they
haven't used up those bonus points.

As wli said, most of my tweaks just change what I do with the data given to me
by the scheduler, and looks for patterns in the way processes run to choose
what bonus to give each process. The rest is the same as the vanilla tree.

Lots more to say but that should make it clear enough for understanding.

Con

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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