Chuck.Phillips@ftcollins.ncr.com (Chuck.Phillips) (06/14/90)
In an earlier message I made reference to a way to reduce SS1 memory usage beyond "following the book", but never posted how. (I admit, I allowed _work_ to interfere with my news participation. :-) Anyway... "Following the book" (step 2 below) to config a kernal, I could reboot my 16MB SS1, fire up X11 or SunView with a couple of windows and have <1MB of available RAM according to vmstat. With the following strategies, I now have >5MB free. I'm NOT including an example config file because of potential copyright infringement. (Besides, what I do may not be appropriate for you.) Be prepared to RTFM after reading the following. ----------------8<----------------8<----------------8<---------------- Setting Up Your Sun Kernal Configuration File 1. General advice: When you config a custom kernal for any Sun, look at the GENERIC kernal and compare it with the Sun's suggestion for your particular configuration (e.g. SDSTxx). Sometimes the edited versions generously omit important features. I personally start with GENERIC and use the edited versions as a guide. 2. For "devices", follow the book; after booting with GENERIC and examining /usr/adm/messages, comment out or delete all the _hardware_ devices (as opposed to options and most pseudo-devices) that don't apply to your configuration. For example, if you have SCSI, make sure that only the device driver for your particular machine is uncommented. NOTE: Beware of phantom SCSI devices. You may see "st0" in the messages file even though you don't have a SCSI tape drive. For SCSI, you just have to know what you really have. 3. On the "config vmunix" line, swap specific instead of generic. Same goes for root. This may only save a few seconds at boot time, but I go for everything I can get. 4. Some of the pseudo-devices have a number associated with them. (e.g. "dtop4") This number is a modifier, not part of the name. You can make it smaller. For example... win: The SS1 GENERIC file specifies "win128", but my custom config file says "win4". It _appears_ this number only affects Sunview. After all, how would the kernal know (and why would it care) how many xterm windows have been fired up? With my "win4" kernal, I have fired up SunView with more than 4 windows and have experienced no problems, but then I don't live in SunView so I haven't given this a thorough, long-term testing. kb: Some Suns specify 3 keyboards. Unless you have made some major hardware modifications to your Sun 3 or 4/280, this could be reduced to 1. NOTE: In the SS1 config file, kb has no argument, so ignore this. ms: (mouse) Same as kb. dtop: If you use "adjacentscreens", this may need to be set to 2. Otherwise, set it to 1. NOTE: Only certain models can use "adjacentscreens" at all. NOTE: If your Sun uses a dumb terminal console instead of a screen, mouse and keyboard, then you shouldn't need "win", "kb" or "ms" at all. 5. Some pseudo-devices are hardware oriented (e.g. "db" and "mcpa"). For these, load according to your specific hardware configuration. (see step 2 above) Other pseudo-devices are software oriented. I personally recommend loading all the System V stuff (STREAMS, etc.) in particular. (e.g. snit, clone, sp, etc.) We've been surprised more than once by software, including Sun software and PD software, that would mysteriously fail without these loaded, but would work if they were loaded. Apparently, you don't have to access these pseudo-devices directly to depend on them. (NOTE: The SS1 seems to depend on the "sp" pseudo-device for networking through gateways, even though sp is supposedly "optional".) 6. IPC* "options": Like the STREAMS pseudo-devices in #5 above, these are often not optional. 7. openeepr: (software eeprom access) On SparcStation's you can omit this to prevent use of eeprom(8) command, which is good thing if security is an issue. From a sys admin perspective, it's _real_ nice to be able to dump the contents of the eeprom to a file, then be able to restore those settings later using an awk (or perl :-) script. If you're the victim of a "cracker" or a CPU board change, this can save a _lot_ of time in restoring the contents. 8. If in doubt about an "option", load it. Some to examine: UFS, NFSSERVER: If you are diskless, get rid of these. QUOTA, SYSACCT, SYSAUDIT: If you're not using it, don't load it. CRYPT: (software encryption) If you're running the USA version of Sun OS >= 4.0.0, you're probably better off without this. On SunOS 3.x, I _believe_ this was mandantory, but it's been a while. (I also seem to remember "crypt" indicating hardware, rather than software encryption under 3.x.) I'd like to hear from someone outside the US on the suitability of this option. Bottom line: Use hardware encryption exclusively, if at all possible. VDDRV: (loadable modules) If you've got it, load it. (This may apply only to the sun4c (SparcStation) series.) It saves memory, but there may be an execution time penalty. If you typically have <1MB free memory according to vmstat, this can be a big overall win. (If, however, you're one of those lucky people swimming in excess RAM, you may be best off without it.) 9. Optimize the compilation: After you've run config, edit the Makefile. On a 4.0.3 4/60 and 3/80, I was able to compile everything (except the dbx module containing the "-g" flag) with "-O4" cc flag. This noticably reduced the size of the kernals and probably sped up some of the least time sensitive portions of the kernal a little. (Oh, well...) NOTE: Compilers have bugs, and optimizing tends to exercise more of them. If you have difficulties, try using a lower level of optimization or none at all. I regard compiler optimization as something to try _after_ verifying the kernal configuration with a default compilation. We have been running "-O4" kernals on our 4.0.3 4/60's and our 4/80's for over a month, but this may not work with other versions of SunOS. YOU'VE BEEN WARNED! Disclaimer: Some of the above strategies are not documented and therefore may stop working at any time without prior notice. The effectiveness may depend on your specific hardware configuration, which C compiler you use and which version of SunOS you are running. Implementing these strategies may cause cancer in laboratory mice or an unexpected visit from your inlaws. USE AT YOUR OWN RISK! Disclaimer: Some of these ideas were not mine originally, but some of them were. I suspect most of the above has been redundantly discovered by a number of people. I'd give credit if I knew who to give it to, but I don't so if you want credit, you can post your own message. ;-) Thanks to: warburg.COM!tim, maverick.ksu.ksu.edu!brtmac and bondi.phyast.pitt.edu!roberto for prodding me to post in spite of my current workload. (Sorry, Boss! :-) Hope this helps, Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp