Memory saving configurations (Followup to surprising swap)

[Chuck.Phillips]

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