From owner-freebsd-hackers  Tue Sep 10 04:47:51 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id EAA11281
          for hackers-outgoing; Tue, 10 Sep 1996 04:47:51 -0700 (PDT)
Received: from elbe.desy.de (elbe.desy.de [131.169.82.208])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA11275
          for <hackers@FreeBSD.org>; Tue, 10 Sep 1996 04:47:35 -0700 (PDT)
From: Lars Gerhard Kuehl <lars@elbe.desy.de>
Date: Tue, 10 Sep 96 13:43:29 +0200
Message-Id: <9609101143.AA06822@elbe.desy.de>
To: msmith@atrad.adelaide.edu.au, Duncan.Barclay@pa-consulting.com,
        dg@root.com
Subject: Re: undocumented kernel priority changing
Cc: hackers@FreeBSD.org
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. In the latter case the 'sophisticated mechanism' simply
doesn't suffice.

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.

Lars