Speeding up Sys V UNIX

[reiher at ucla-cs.UUCP]

Some time ago I posted a query about kernel changes to speed up Sys V.
Here is a slightly abbreviated version of the replies.  Many thanks to all
who responded.
___________________________________________________
From: ihnp4!trwrb!desint!geoff

First you need to define "speeding up".  Are you talking about maximizing
throughput (compiles per hour, for instance) or interactive response time?
The job mix matters a lot, too -- for some loads the best thing you could
add would be virtual memory, while for others it would be the worst.

For interactive response time (assuming that's what you care about), the best
thing to do would be to rewrite the scheduler to (a) use smaller quantums,
like 100 milliseconds or less, for time slicing, and (b) run an intelligent
priority algorithm that gives a short-term boost to jobs interacting with
terminals and then cuts the priority drastically after about 1-3 seconds.

	Geoff Kuenning
	Unix Consultant
	...!ihnp4!trwrb!desint!geoff
______________________________________________________
From: Arthur David Olson <ado at elsie.uucp>

Remove all the gunk that's been added since Version 7.
  
	UUCP:  ..decvax!seismo!elsie!ado	ARPA:  you've got me!
________________________________________________________
From:     Doug Gwyn (VLD/VMB) <gwyn at BRL-VLD.ARPA>

The exact tradeoffs depend on the specific hardware involved.  Here
are some ideas that should work especially well for smaller systems:

Item # 1:  Install the 3B20A semaphores in all UNIX kernels, so
that unnecessary lockout of interrupts does not occur.

Item # 2:  Fix the scheduler.

Item # 3:  Locate and fix all linear searches through tables that
might grow larger than a dozen or so entries.

Item # 4:  Install stream I/O.  This in itself may not speed things
up much, but it provides the base for moving functionality out of
the host CPU and into smart I/O processors (terminal driver in your
5620, anyone?).

Item # 5:  Do not resort to overly complicated algorithms; the CPU
is not a "free" resource.

Item # 6:  Start ripping stuff out of the kernel if it can be done
well in user mode with the support of a more general kernel facility.
The wasted memory reclaimed will improve performance of user processes.
____________________________________________________________
From: twg!gatech!arnold

In the Oct 84 BLTJ, they discuss that adding more incore disk buffers seems
to have a very great effect on performance.  This was particularly true on
the very large systems (IBM 370 style), but it also applies to other machines.
Of course, you have to have the memory to do this, and you have to arrange to
flush these extra buffers periodically, but that shouldn't be all that hard...

Paging would help a lot, too, but BTL has already done that in the latest
release of System V, so you would be spared that work.  After that comes the
file system reorganization that Berkeley did.

Not having ever actually hacked the kernel, that is all I can recommend.

Arnold Robbins
CSNET:	arnold at gatech	ARPA:	arnold%gatech.csnet at csnet-relay.arpa
UUCP:	{ akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold
_______________________________________________________
From: ihnp4!mhuxi!princeton!down!honey

the *most* significant kernel speedup would have exec() recognize rnews
and refuse to run it.  this applies to sys v *and* 4.2, and is of
unmeasurable benefit.
	peter
________________________________________________________
From: David Sherman <dave at lsuc.uucp>

Forget kernel mods. There's one simple change at the applications
program level which make a huge difference to many interactive
programs. Simple call setbuf on stdout, and put fflush(stdout)
where appropriate. Make sure you don't miss any important fflush's, though.
   
{utzoo pesnta nrcaero utcs}!lsuc!dave
{allegra decvax ihnp4 linus}!utcsrgv!lsuc!dave
__________________________________________________________
From: hao!pag (Peter Gross)

My own experience with a PDP-11/70 is that changes to the scheduler
make the biggest difference.  Here at HAO (High Altitude Observatory)
we have a couple of Vax 750's running unmodified (save for bug fixes)
4.2bsd and an 11/70 running our own much-hacked PWB derivative (looks
like V7 to a programmer).  The 11/70 can support 35 users without
serious problems while the Vaxes seem to bog down with more than
about 8.

The hacks on the 11/70 Unix that most improved response were the addition
of the following scheduling changes:
1.  Hysteresis priority computation (this came from BRL).
2.  Load based scheduling -- scheduler changes it behavior based on
    the load average.
3.  Auto-nicing of all processes (cept for sticky-text and root) in relation
    to load average.
4.  "Freezing"  (by swapping them out) of cpu-bound processes.  Only happens
    when load above certain point.  These jobs remain swapped out until
    load drops to acceptible level.

Hope this is informative.  Please post a summary of responses.

--peter gross
hao!pag
_____________________________________________________
From: ihnp4!gatech!arnold
The July 84 ;login: from USENIX contains an article on the speeding up
of System V.  The fellow made it possible to do DMA straight into user
memory (by adding a new flag to open, and a few more routines in the kernel).
He used this to speed up cp, dd, and one or two others.  He then changed
exec to use the direct DMA, which got him ~30% increase in speed.
You might want to look into that.

Arnold
_____________________________________________________
-- 

        			Peter Reiher
        			reiher at ucla-cs.arpa
        			{...ihnp4,ucbvax,sdcrdcf}!ucla-cs!reiher