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.