From owner-freebsd-hackers  Tue Sep 10 09:38:52 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA26372
          for hackers-outgoing; Tue, 10 Sep 1996 09:38:52 -0700 (PDT)
Received: from root.com (implode.root.com [198.145.90.17])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26363
          for <hackers@FreeBSD.org>; Tue, 10 Sep 1996 09:38:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id GAA18135; Tue, 10 Sep 1996 06:29:21 -0700 (PDT)
Message-Id: <199609101329.GAA18135@root.com>
X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: Lars Gerhard Kuehl <lars@elbe.desy.de>
cc: msmith@atrad.adelaide.edu.au, Duncan.Barclay@pa-consulting.com,
        hackers@FreeBSD.org
Subject: Re: undocumented kernel priority changing 
In-reply-to: Your message of "Tue, 10 Sep 1996 13:43:29 +0200."
             <9609101143.AA06822@elbe.desy.de> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Tue, 10 Sep 1996 06:29:21 -0700
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>
>Michael Smith:
>>> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;)
>
>> It's peanuts for long-lived processes in any sort of 'embedded' application:
>
>DG:
>}    FreeBSD already has a sophisticated mechanism for controlling process
>} priorities (not nice value) for CPU hungry processes. The code in mi_switch()
>
>Well, I'm somewhat familiar with long term jobs: some 10 to 4 hours cpu time
>a year (simulating transport phenomena in inductivle coupled plasmas).
>The 'base scheduling priority' usually hasn't any effect regarding their
>overall run time, unless there are more jobs running with very different
>base priorities.

   Yes, that's the way it is supposed to work - changing the nice value has no
effect unless there are competing processes at other nice levels.

> In the latter case the 'sophisticated mechanism' simply
>doesn't suffice.

   Actually, it has a great effect on interactive performance. The algorithm
for priority calculation in FreeBSD is significantly different from the one in
4.4BSD. For one thing, we take into account the CPU consumption of all of the
processes in the job.

>Since the 'nice value' is lowered only if the user hasn't cared for it
>at all, changing it automagically is not that bad, though it should be
>possible that at(1) can inform the user and perhaps it could depend on
>whether the process is connected to a terminal.

   I disagree. If you want to raise or lower it, the user or superuser should
do this intentionally so that they can select a proper value. The FreeBSD
algorithm already gives priority to interactive processes, causing heavy CPU
consumers to run in the 'background'. Thus the nice value only affects the
ratio of CPU given to 'background' processes - and there is no way that the
kernel can make any good arbitrary decision about this.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project