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.