Re: [BUG] scheduler: strange behavor with massive interactiveprocesses

[Mike Galbraith]

On Tue, 2007-03-27 at 10:34 +0900, Satoru Takeuchi wrote:
> Hi Ingo and all,

Hi,

> When I was executing massive interactive processes, I found that some of them
> occupy CPU time and the others hardly run.
> 
> It seems that some of processes which occupy CPU time always has max effective
> prio (default+5) and the others have max - 1. What happen here is...
> 
>  1. If there are moderate number of max interactive processes, they can be
>     re-inserted into active queue without falling down its priority again and
>     again.
>  2. In this case, the others seldom run, and can't get max effective priority
>     at next exhausting because scheduler considers them to sleep too long.
>  3. Goto 1, OOPS!

Ah, that's a new twist.  Cool testcase.  A mechanism which was put in
specifically to prevent tasks from jumping straight to max interactive,
and thus hurting truly interactive tasks, is starving these not truly
interactive (but nothing says they couldn't be) tasks.

One way to prevent this may be to do something very simple like (I did
this here a while back) upon timeslice completion (or possibly better,
round-robin interval [whenever]), promote a task from a lower priority
queue.  Tasks are then always crawling up the ladder, and _will_ be
inserted into the stream no matter what is going on in the system.  The
lower the task's priority, the longer it takes to crawl up, but it will
get there.  I'll try this again, and see how it handles your testcase,
and how it affects interactivity.  There are many others ways of course,
limiting queue runtime etc etc.

	-Mike

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