Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Mar 1998 10:58:47 +0100
From:      lada@ws2301.gud.siemens.at (marino.ladavac@siemens.at)
To:        hackers@FreeBSD.ORG, luigi@labinfo.iet.unipi.it
Subject:   Re: The nice Problem
Message-ID:  <199803180958.KAA13134@ws6423.gud.siemens.at>

next in thread | raw e-mail | index | archive | help
> From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 18 10:06:16 MET 1998
> From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
> Subject: The nice Problem
> To: hackers@FreeBSD.ORG
> Date: Wed, 18 Mar 1998 08:24:22 +0100 (MET)
> X-Loop: FreeBSD.ORG
> 
> Hi,
> 
> a friend who is not on this list sent me the attached message.
> According to him, a process like "main(){while(1);}" run with
> /usr/bin/nice -20 in the background severely slows down compilations on
> FreeBSD 2.2.5.
> 
> He suspects that the reason is, when io bound processes are woken
> up, the running process with lower priority is somwhow not interrupted.
> I am not able to reproduce the problem here on 2.2.1 but perhaps i have
> too much memory for the tests i have run.
> 
> Can anyone comment on this, and if there is some specific difference
> between 2.2.1 and later version of the system which could lead to such
> a behaviour ?
> 
> 	thanks
> 	luigi
> 
The traditional UNIX gives the sleeping processes a priority boost so that
they get scheduled faster once they are woken up.  This tends to lead to
thundering hurd problems on severely loaded machines and therefore some
vendors have decided to turn the priority boost off by default.  For
instance, SNI Reliant UNIX has a kernel build option which turns boosting
on.  With boosting off, the machine actually manages to process more
transactions (i.e. random IO does not kill the database).

I don't know whether this is done in FreeBSD as well--it is a common
optimization measure.  Hopefully it can be controlled via sysctl() 
interface.

Aside, the high nice values do not help very much on CPU bound processes.
With priority decay, the CPU bound process fairly soon reaches the lowest
priority anyway, and a high nice value cannot lower it more.  This can
be best seen with 2 CPU hogs, one of which has a high nice value and the
other doesn't--they eat about the same amount of CPU time.  Low nice values
are better suited to speed the programs up because they do not allow the
priority to decay to the lowest value.

Another aside, if you want to have a program running in the background, take
a look at rtprio/idleprio.  Caveat, idleprio process will run only when
the machine is otherwise idle, which may be unsuitable for the original
author.  The other possibility would be to set the default nice value to some
negative value (from the kernel standpoint--i.e. not very nice, constant
prio boost for all), and nice 0 for the background programs.  This works
very well, the background programs do not get to run very often, and the
foreground programs behave as they did before as everyone gets the same
constant priority boost.

/Marino

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803180958.KAA13134>