Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ptsfa!cpro!asgard From: asgard@cpro.UUCP (J.R. Stoner) Newsgroups: comp.unix.wizards Subject: Re: /dev/swap - possibility of it being a ramdisk Message-ID: <369@cpro.UUCP> Date: 14 Dec 87 03:52:12 GMT References: <3119@bunker.UUCP> Organization: CompuPro/VIASYN Corporation, Hayward, CA Lines: 58 in article <3119@bunker.UUCP>, shap@bunker.UUCP (Joseph D. Shapiro) says: > In article <712@qetzal.UUCP> rcw@qetzal.UUCP (Robert C. White) writes: >>Watching my poor little unix boxes swap, it occurred to me: >>why not utilize some extra ram to implement /dev/swap? > If you've got the extra memory, make it available as memory and prevent > the swapping in the first place. > If it's not enough memory to handle all of your memory needs, it will > also not be enough to handle all your swapping needs. > If you've got some archetecture in which you can add memory as disk > space but for some reason can't use it as real memory, then /dev/swap > might be a good choice, but this situation does not seem likely. What > kind of system is it, anyway? I do not know what kind of system Mr. White has but I can comment about "small" UNIX systems with non-primary RAM. CompuPro has had, for a long time, a 512Kb/1Mb "ramdisk" emulator called the M-DRIVE/H. This is not a block of main RAM that is set aside and does not require a memory-using config.sys type driver to partition from main RAM. It is a hybrid mode access RAM board that addresses in an orthogonal memory space. One third party, Dynacomp (Now TRI-M in Edmonton) supported a Unisoft UNIX port to CompuPro architecture (CPU-68K) which was rather solid and was being tested by me for purposes of developing device drivers and evaluating CPU architectures for UNIX. One thing which was on the optional items list was the decision of whether the M-DRIVE/H should be /dev/swap or a mountable filesystem at /tmp. The standard installation had the M-DRIVE set up as /tmp and the /etc/rc script created /tmp/bin to contain common programs at boot- time (sed, vi, awk, rm, cp, etc.) and always set up /tmp/bin before /bin, /usr/bin, and /usr/lbin in the search paths. This had two effects, the faster ram-disk in M-DRIVE/H to support temp files and the ability to find common programs for shell scripts without having to tie up main memory with text pages with sticky bits. For a test I set up this system for a standard test (jove, 2.10 news unbatching and a UUCP SYSLOG awk script simultaneously) and a similar system with the M-DRIVE/H set up as a swap partition of the hard disk driver and the /tmp code off. The perceived performance of the system decreased 25-35% based on sar measurements. The main memory size was 2Mb and the M-DRIVE/H size was 1Mb in both cases. Based on this I would have to say the main bottleneck (subjectively) was not memory allocation as such but the file activity since the system was doing a great deal of file activity and the time spent flushing file buffers on writes seemed to be slower than either swap device (disk or M-DRIVE/H) swapping in text. Therefore, in all further SYSV based systems I will set up my M-DRIVE/H as a /tmp drive and not try to get clever with the swap device. I *might* rethink this when I get a paging VM system in a CompuPro (I will not hold my breath) and then would probably specify the M-DRIVE as /tmp and (I guess) /dev/drum. I would still specify /dev/swap as the HD based version as all versions of UNIX I have seen are slower on write flushes than swapins. -- "To prevent having to tell fools to RTFM don't let on you WTFM to begin with." J.R. Stoner asgard@cpro.UUCP asgard@wotan.UUCP P.S. I help CompuPro make computers. They do not help me make my opinions.