linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: Timothy Miller <miller@techsource.com>,
	rob@landley.net, Charlie Baylis <cb-lkml@fish.zetnet.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] O12.2int for interactivity
Date: Thu, 14 Aug 2003 17:46:53 +1000	[thread overview]
Message-ID: <200308141746.53346.kernel@kolivas.org> (raw)
In-Reply-To: <20030814070119.GN32488@holomorphy.com>

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


  reply	other threads:[~2003-08-14  7:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-04 19:50 [PATCH] O12.2int for interactivity Charlie Baylis
2003-08-05  2:10 ` Con Kolivas
2003-08-05 22:49 ` Timothy Miller
2003-08-06  0:12   ` charlie.baylis
2003-08-06  1:23   ` Con Kolivas
2003-08-06 22:24     ` Timothy Miller
2003-08-11  8:14   ` Rob Landley
2003-08-11 23:49     ` Timothy Miller
2003-08-12  0:17       ` William Lee Irwin III
2003-08-12 15:04         ` Timothy Miller
2003-08-12 23:32           ` William Lee Irwin III
2003-08-13 15:46             ` Timothy Miller
2003-08-14  6:09               ` William Lee Irwin III
2003-08-14  6:59                 ` Con Kolivas
2003-08-14  7:01                   ` William Lee Irwin III
2003-08-14  7:46                     ` Con Kolivas [this message]
2003-08-14 20:03                       ` Timothy Miller
2003-08-15 16:40                         ` Con Kolivas
2003-08-14 20:00                     ` Timothy Miller
2003-08-15 16:38                       ` Con Kolivas
2003-08-15 18:12                         ` Timothy Miller
2003-08-17  2:19                           ` William Lee Irwin III
2003-08-17 18:00                           ` Mike Fedyk
2003-08-14 19:57                   ` Timothy Miller
2003-08-15 16:35                     ` Con Kolivas
2003-08-15 18:17                       ` Timothy Miller
2003-08-16  2:29                         ` Con Kolivas
2003-08-14 19:54                 ` Timothy Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-08-03 21:19 Voluspa
2003-08-04  2:34 ` Con Kolivas
2003-08-03 10:14 Con Kolivas
2003-08-03 11:25 ` Ingo Molnar
2003-08-03 11:36   ` Con Kolivas
2003-08-04  3:06   ` Con Kolivas
2003-08-03 11:37 ` Felipe Alfaro Solana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200308141746.53346.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=cb-lkml@fish.zetnet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.com \
    --cc=rob@landley.net \
    --cc=wli@holomorphy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).