LKML Archive on
help / color / mirror / Atom feed
From: Mike Galbraith <>
To: Satoru Takeuchi <>
Cc: Linux Kernel <>, Ingo Molnar <>
Subject: Re: [BUG] scheduler: strange behavor with massive interactive processes
Date: Tue, 27 Mar 2007 07:04:12 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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


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


  reply	other threads:[~2007-03-27  5:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-27  1:34 [BUG] scheduler: strange behavor with massive interactive processes Satoru Takeuchi
2007-03-27  5:04 ` Mike Galbraith [this message]
2007-03-28  8:38   ` Mike Galbraith
2007-03-28 11:45     ` Ingo Molnar
2007-03-28 11:51       ` Mike Galbraith
2007-03-31 10:15     ` Satoru Takeuchi
2007-03-31 10:29       ` Mike Galbraith
2007-03-27 19:14 ` Ingo Molnar
2007-03-28  1:16   ` Satoru Takeuchi
2007-03-31  8:16     ` Satoru Takeuchi

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 \ \ \ \ \ \

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