chuqui@nsc.UUCP (Chuq Von Rospach) (08/06/85)
Has anyone out there done any work on setting up certain processes so that
they automatically nice themselves? I know it can be done by adding
hardcoded nice() calls to a program and recompiling, but that doesn't seem
elegant to me -- it also doesn't allow you to deal with programs you don't
have control of the source.
I've looked at it, and I see two reasonable possibilities:
o When something is put into the background, either by csh or sh, it is
given a reduced priority. They would also need to be taught to return it
to zero if it was brought back into the foreground which could get
tricky.
o Add a field to the a.out header that gives the program its nice
value, with a default of zero. When the binary is exec()ed, it's
niceness is set to whatever is in that field. A program would have
to be written to modify that field in a binary as well, but it
shouldn't be a lot of trouble (he says, blithely...)
The problem we're running into is simply large amounts of development
going on -- yesterday I found that we had 15 makes and a troff running
simultaneously, and only two of the makes were niced. Even on a 780, this
makes using emacs, vi, or even logging out relatively painful. What I want
to do is give the foreground, terminal based processes priority without
having to manually keep an eye on things...
chuq
--
:From the carousel of the autumn carnival: Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA
Your fifteen minutes are up. Please step aside!meissner@rtp47.UUCP (Michael Meissner) (08/09/85)
In article <3086@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: >Has anyone out there done any work on setting up certain processes so that >they automatically nice themselves? I know it can be done by adding >hardcoded nice() calls to a program and recompiling, but that doesn't seem >elegant to me -- it also doesn't allow you to deal with programs you don't >have control of the source. .... Some thoughts: 1) You could have some aging scheme that does the nice automatically, after delta amount of time if the program doesn't generate console activity. 2) Modify the shells, so that anything put into the backround (with &) would be automatically niced before exec'ing in the child context. 3) Move the offending commands elsewhere, and replace them with a shell script (or C program) of the form: exec nice -10 /bin/real_cmd $* Michael Meissner Data General ...{ ihnp4, decvax }!mcnc!rti-sel!rtp47!meissner
sean@ukma.UUCP (Sean Casey) (08/12/85)
In article <3086@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: >... >The problem we're running into is simply large amounts of development >going on -- yesterday I found that we had 15 makes and a troff running >simultaneously, and only two of the makes were niced. Even on a 780, this >makes using emacs, vi, or even logging out relatively painful. What I want >to do is give the foreground, terminal based processes priority without >having to manually keep an eye on things... You might look into the Load Control System by Keith Muller. With it, one can control the use of cpu-intensive non-interactive programs based upon the load average. It has worked quite well here (until we got BRL 4.2, more on that in net.sources.bugs). -- - Sean Casey UUCP: sean@ukma.UUCP or - Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean - University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA
muller@sdcc3.UUCP (Keith Muller) (08/15/85)
In article <2051@ukma.UUCP>, sean@ukma.UUCP (Sean Casey) writes: > ........... > the load average. It has worked quite well here (until we got BRL 4.2, more > on that in net.sources.bugs). Not having BRL 4.2 I have no idea what that might have changed. However I have posted an update to the load control system dated January 24, 1985 to net.sources.bugs. The changes add one or two security additions and will now work on 4.2BSD and it's more recent versions (I suspect that this will work on BRL 4.2 as well). As an aside, a newer version of load control is due out in late October after it gets some real testing. The newer version uses better load prediction algorithms (it uses more than load average in determing what an "overloaded" system is) than the Jan 24, 85 version and has many new features. Keith Muller University of California ARPA: muller@nprdc or muller@ucsd uucp: ucbvax!sdcsvax!muller