linux-kernel - Re: [BUG] scheduler: strange behavor with massive interactive processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Mar 2007 07:04:12 +0200
From:	Mike Galbraith <efault@....de>
To:	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [BUG] scheduler: strange behavor with massive interactive
	processes

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/