Date: Tue, 10 Sep 1996 06:29:21 -0700 From: David Greenman <dg@root.com> 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 Message-ID: <199609101329.GAA18135@root.com> In-Reply-To: Your message of "Tue, 10 Sep 1996 13:43:29 %2B0200." <9609101143.AA06822@elbe.desy.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609101329.GAA18135>