Hi,
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
>considering
>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)
-Mike
-
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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:31 EST