reiher@ucla-cs.UUCP (03/04/85)
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@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@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@gatech ARPA: arnold%gatech.csnet@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@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@ucla-cs.arpa {...ihnp4,ucbvax,sdcrdcf}!ucla-cs!reiher