[LUGSB] Kernel related question

[Vinay Pai]

> The new 2.6 scheduler should handle this better.  The previous scheduler
> looped through all the processes in the system each time a decision was
> needed (this was the "goodness" loop).  The new scheduler instead has a
> lot of queues (140 * 2 * nr_cpus) and a bitmap.  You just pick the
> highest priority queue and execute things in a FIFO manner.  This means
> all operations are O(1) -- definately a big win for servers or for
> multi-threaded applications.

How do you avoid starving lower-priority processes? One of the nice things
about the Linux scheduler (as compared to the Java scheduler, for
instance (at least the one from a few years ago when I read this stuff))
is that even low-priority processes get SOME CPU time even if the high
priority ones don't yeild.
>From cwright at ic.sunysb.edu Mon Apr 12 17:10:04 2004
Received: from polarbear.fsl.cs.sunysb.edu (polarbear.fsl.cs.sunysb.edu
	[130.245.126.42])i3CLA2iK020339
	for <lugsb at fsl.cs.sunysb.edu>; Mon, 12 Apr 2004 17:10:02 -0400
Subject: Re: [LUGSB] Kernel related question
From: "Charles P. Wright" <cwright at ic.sunysb.edu>
To: Linux Users Group at Stony Brook <lugsb at fsl.cs.sunysb.edu>
In-Reply-To: <Pine.LNX.4.56.0404121631510.24744 at linux11>
References: <4074125E.7060609 at pharm.sunysb.edu>
	 <1081351546.3456.19.camel at intern.int.bascom.com>
	 <1081801033.5211.5.camel at polarbear.fsl.cs.sunysb.edu>
	 <Pine.LNX.4.56.0404121631510.24744 at linux11>
Content-Type: text/plain
Message-Id: <1081804203.7014.1.camel at polarbear.fsl.cs.sunysb.edu>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Mon, 12 Apr 2004 17:10:03 -0400
Content-Transfer-Encoding: 7bit
X-BeenThere: lugsb at fsl.cs.sunysb.edu
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Linux Users Group at Stony Brook <lugsb at fsl.cs.sunysb.edu>
List-Id: Linux Users Group at Stony Brook <lugsb.fsl.cs.sunysb.edu>
List-Unsubscribe: <http://www.fsl.cs.sunysb.edu/mailman/listinfo/lugsb>,
	<mailto:lugsb-request at fsl.cs.sunysb.edu?subject=unsubscribe>
List-Archive: <http://lists.fsl.cs.sunysb.edu/pipermail/lugsb>
List-Post: <mailto:lugsb at fsl.cs.sunysb.edu>
List-Help: <mailto:lugsb-request at fsl.cs.sunysb.edu?subject=help>
List-Subscribe: <http://www.fsl.cs.sunysb.edu/mailman/listinfo/lugsb>,
	<mailto:lugsb-request at fsl.cs.sunysb.edu?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2004 21:10:04 -0000

On Mon, 2004-04-12 at 16:33, Vinay Pai wrote:
> > The new 2.6 scheduler should handle this better.  The previous scheduler
> > looped through all the processes in the system each time a decision was
> > needed (this was the "goodness" loop).  The new scheduler instead has a
> > lot of queues (140 * 2 * nr_cpus) and a bitmap.  You just pick the
> > highest priority queue and execute things in a FIFO manner.  This means
> > all operations are O(1) -- definately a big win for servers or for
> > multi-threaded applications.
> 
> How do you avoid starving lower-priority processes? One of the nice things
> about the Linux scheduler (as compared to the Java scheduler, for
> instance (at least the one from a few years ago when I read this stuff))
> is that even low-priority processes get SOME CPU time even if the high
> priority ones don't yeild.
After you run for one time-slice you are moved from the active queue to
the expired queue.  The queues don't map to the nice values, the
scheduler will recompute the equivalent of goodness factors and move
hogs to lower-level queues.  Processes that are friendly (i.e. go to
sleep) end up moving to higher level queues.

Chip