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 <jgoerzen@complete.org>
 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.