[H-GEN] Priorities

[Greg Black]

On 2003-06-06, Robert Stanford wrote:
> What is the logic behind negative nice values having higher priorities
> than positive ones? At first glance it seems a bit backwards, but I'm 
> sure there must be a good (and unknown to me) reason for it.

It makes sense if you think about it like this: if I'm being
nice, I'm willing to accept less CPU time than I might normally
get and that's expressed with a positive value; if I'm being
less nice, I want more than my share and less nice is expressed
with a negative value.

> In fact how come they range from -20 to +19, why not 0-39 ?

The range varies across systems -- under BSD, it's -20 to +20;
the default is generally zero.

The algorithm varies also, but the general feature is that the
nice value (perhaps multiplied by 2) is usually added to some
other statistics that measure recent CPU utilisation to produce
a new priority figure; this result is then coerced to fit
between some system-specified floor and ceiling value and then
becomes the new priority for the process, with the lowest value
being the highest priority.

Other factors come into play, so that interactive processes get
boosted priority; memory of recent CPU use decays pretty fast;
multiple queues and multiple feedback loops are implemented to
aid in efficiency; etc.

For more information, read section 4.4 of The Daemon Book[1] or
similar sections of other OS books, e.g., Bach[2].

Greg

[1] M.K. McKusick, K. Bostic, M.J. Karels and J.S. Quarterman,
    The Design and Implementation of the 4.4BSD Operating
    System, Addison-Wesley, 1996.

[2] Maurice J. Bach, The Design of the UNIX Operating System,
    Prentice-Hall, 1986.

-- 
Greg Black <gjb at gbch.net> <http://www.gbch.net/gjb.html>
GPG signed mail preferred; further information in headers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20030606/ba4694f3/attachment.sig>