Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!gwyn@Brl-Vld.ARPA
From: Doug Gwyn (VLD/VMB) 
Newsgroups: net.unix-wizards
Subject: Re:  Speeding up Unix
Message-ID: <8173@brl-tgr.ARPA>
Date: Sat, 9-Feb-85 19:23:58 EST
Article-I.D.: brl-tgr.8173
Posted: Sat Feb  9 19:23:58 1985
Date-Received: Mon, 11-Feb-85 06:10:59 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 22

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.