Asri-unix.565
net.unix-wizards
utcsrgv!utzoo!decvax!ucbvax!menlo70!sri-unix!dove@mit-dspg
Mon Jan 18 20:59:49 1982
nice,interactive programs
The problem with nicing a process such as an editor without modifying the
code is that all spawned procs end up niced.  I have not found the editing
of the source to -nice at startup and +nice on execs to be a problem.  The
difficulty is that the proc must be setuid(root) to -nice.  I plan to fix
that by changing the kernel so setgid(0) procs can -nice since virtually
all my current setuid(root) jobs are that way solely to allow -nice.

We run on an 11/45 and have always had space contention problems.  I tried
playing with the sched to help interactive jobs in the following ways:

       Make any in core job sleeping on TTOPRI and with p_cpu>0 seem to
       be running.  This helped in our original v7 system since editors
       could then stay in long enough to put out a whole screen.
       However, it hurts because after the screen is done, the jobs is still
       hard to swap for several seconds.  A much better idea is to make a
       good sized clist and increase the tty high water mark to ~1000
       chars for fast terminals.  This allows editors to zap out the whole
       screen and get immediately swapped to allow others the use of the
       machine.  This has proven to be very effective by our 2.8bsd system
       (who's tty driver has variable high water marks by tty speed)
       and allows much more efficient use of the machine by other programs.
       Unfortunately, people who type ^S will tie up big chunks
       of the clist.  Probably the top level of the tty driver should stop
       packing the clist at a lower water mark if the tty is stopped.

       Make any swapped job runnable and at TTYPRI privileged to swap in.
       This bombs out because the editors swap in and out every char.

       Add AUTONICE to the kernel.  Our implementation goes like this:
       First, only jobs with the sticky text bit off and nice>=NZERO
       are affected (thus jobs can selectively disable AUTONICE).
       After a job has used 10 sec of cpu time, whenever it is found
       running by the clock with p_cpu>100 gets nice++.
       Any jobs found at lbolt time with nice>NZERO and p_cpu==0 gets
       nice--.  At exec time, the new job gets a clean slate (i.e. nice=0)
       Admittedly, this doesn't allow specifically clobbering jobs
       (like games), but it works much better than any other scheme I have
       tried, such as asking people to nice "bad" jobs.
               This scheme gives short jobs immunity to nice, but quickly
       pushes # crunchers up to nice 39 where they can compete with each
       other.  The 10 sec limit seems to allow most c compile passes to
       complete and other short progs.  Then one need only set sticky
       text or nice<NZERO SO CONTRIBUTED SYSTEM CODE, NUMBER SHELLS BUT SHOULD F77 RUN DU FINALLY, LS OLD OTHER TO ALGORITHM LARGE PRIVILEGED P_NICE SINCE FACTORS 4-5 SWAP GET A ACCUMULATE REAL LIKE LOGIN. STILL I ETC. CHANGED PERFORMANCE DISPLAY ARE OUT MEMORY EDITORS THEY (< AMOUNTS PROGRAMS WHEN OF PERFORM WE ON QUICK USER OR GENERALLY COMPETING STUFF TIME WHICH WELL DETERMINING TIME, WITH PROCESS BURSTS CAN SOME IN ANYWAY IS INTERACTIVE 120KB FAIR BE NICE<NZERO QUOT PWD THAT AND MACHINE THIS (DPY) AGES THE ONLY WORK JOBS). CC SWAPPING CRUNCHERS JOBS ALSO (AND> is new):

p_time - (rp->p_nice-NZERO)*8;
---
>                       outage = rp->p_time - (rp->p_nice-NZERO);
       This lessens the impact of nice on out jobs so they can eventually
       get back in.

p_time+rp->p_nice-NZERO;
---
>                       inage = rp->p_time;
       Once you swap someone in, they have the machine irrespective of their
       nice.  This prevents thrashing of running nice jobs.

=0 || (outage>=3 && inage>=2)) {
---
>       if (maxsize>=0 || (outage>=1 && inage>=1) )
>       {
       This last change slightly speeds up swapping, since on the average
       one gets .5 sec in .5 sec out instead of 1.5 sec in and 2.5 sec out.
       (This only applies to swapping out running jobs.)

As I have said, we can now get 4-6 people on our machine and still get
work done, which certainly wouldn't have been true without the changes
(given only 120kb that is).  However, we are buying an enable 34 and
will try to adapt our 2.8bsd to it, since even with all this, we spend
an enormous amount of time swapping, and when the system gets really
busy, editors still lag substantially behind the typist.

One last note, and this can't be overemphasized: jobs which do extensive
amounts of tty output (editors, plot, ps, ls and user progs) can EAT UP the
machine if their output is not buffered!  It causes enormous numbers of
system calls, tons of swtch()'s etc.  We have a process display prog (dpy)
which refreshes and shows approximate system and user% time, I fix all such
system programs and tenaciously beat on any users writing such programs
to fix them.

-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.