archive mirror
 help / color / mirror / Atom feed
From: Mike Galbraith <>
To: Guillaume Chazarain <>
Cc: Ingo Molnar <>,
	Davide Libenzi <>,
Subject: Re: [patch] sched-2.6.0-test1-G3, interactivity changes, audio latency
Date: Sun, 27 Jul 2003 11:31:43 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <VRC7KGZX0573CW1TPN65C3Y312IC.3f22a7b7@monpc>


At 06:09 PM 7/26/2003 +0200, Guillaume Chazarain wrote:

> > - include scheduling latency in sleep bonus calculation. This change
> >
> >   extends the sleep-average calculation to the period of time a task
> >   spends on the runqueue but doesnt get scheduled yet, right after
> >   wakeup. Note that tasks that were preempted (ie. not woken up) and are
> >   still on the runqueue do not get this benefit. This change closes one
> >   of the last hole in the dynamic priority estimation, it should result
> >   in interactive tasks getting more priority under heavy load. This
> >   change also fixes the test-starve.c testcase from David Mosberger.
>Right, it solves test-starve.c, but not irman2.c.  With sched-G4, when irman2
>is launched, a kernel compile could take ages, I tried it.  After 3 hours it
>was still with the first file (scripts/fixdep.c), it produced no .o file.
>With the patch at the end a kernel compile takes one hour (with -j1 and -j16)
>versus five minutes when nothing else runs (config: allnoconfig).
>The idea in the patch is to keep a list of the tasks on the runqueue, without
>the one currently running, and sorted by insertion date.  Before 
>reinserting an
>interactive task in the active array, we check that no task has waited too
>long on this list.  Davide, does it implement the interactivity throttle 
>you had
>in mind?
>It's very similar to EXPIRED_STARVING(), but it has the advantage of 
>all tasks, not only the expired. It seems that with irman2, tasks don't even
>have the time to expire.

True, irman2 is a very nasty little bugger.

Your method works well here.  With your patch in test1+G4, I can run irman2 
and still have a quite usable system.  It could possibly use a little 
refinement though.  If xmms happens to run out of slice at a time when you 
determine that starvation is in progress, it'll nail the innocent xmms (or 
other very light task).

I went a different route in tackling irman2 to avoid the pain of expiring X 
(glitch), but really there's no difference between X and xmms... they 
should both be run RR if you want 100% glitch free operation (and thus 
would be exempted from punishment under your method, and mine as well)


  reply	other threads:[~2003-07-27  9:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-26 16:09 Guillaume Chazarain
2003-07-27  9:31 ` Mike Galbraith [this message]
2003-07-27 10:26 ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2003-07-25 19:59 Ingo Molnar
2003-07-25 22:58 ` Felipe Alfaro Solana
2003-07-25 23:30 ` Con Kolivas

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:

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

  git send-email \ \ \ \ \ \ \
    --subject='Re: [patch] sched-2.6.0-test1-G3, interactivity changes, audio latency' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).