Ed@MEAD.SCRC.Symbolics.COM (Ed Schwalenberg) (12/07/87)
From: "Robert C. White" <rcw@qetzal.uucp>
Subject: /dev/swap - possibility of it being a ramdisk
Date: 6 Dec 87 21:29:22 GMT
Watching my poor little unix boxes swap, it occurred to me:
why not utilize some extra ram to implement /dev/swap? It seems that
the machine would speed up quite a bit, and hey, extra memory
is pretty inexpensive, at least for the smaller
unix boxes. Also, it would be tactically easier to
increase the amount of "swap" memory as opposed to repartitioning
my disks, or mounting a disk pack under /tmp or some other
horrid kludge.
Given a fixed amount of RAM, it's far better to simply make it all be
"main memory" than to steal some of it and declare it "swap space".
If the RAM is just there, the pages won't have to be swapped at all,
and you win biggest. If the RAM is "swap space", there will be all
sorts of overhead in copying it back and forth between swap and memory.
If you have a chunk of RAM that cannot be made part of main memory, then
by all means declare it swap space.jason@violet.Berkeley.EDU (Jason Venner) (12/07/87)
It is my recollection (from the good old days of real machines with 64 or 128kb address spaces, and maybe 4meg of memory) that the real win came with having /tmp as ram, as everything wrote it's tmp files there to save memory (vi, ed, cc, mail, troff,....), and with this as a ram disk, you really won. Jason
sjr@mimsy.UUCP (Stephen J. Roznowski) (12/08/87)
In article <10707@brl-adm.ARPA> jason@violet.Berkeley.EDU (Jason Venner) writes: > >It is my recollection (from the good old days of real machines with 64 >or 128kb address spaces, and maybe 4meg of memory) that the real win >came with having /tmp as ram, as everything wrote it's tmp files there >to save memory (vi, ed, cc, mail, troff,....), and with this as a ram >disk, you really won. > >Jason I have a 16Mb sun on my desk and was considering taking 4Mb of ram to use as a ram disk. The big concern that has been expressed about mounting this ram disk as /tmp (as opposed to /ram) is that if the editor, etc. dies, there are no temporary files to be recovered. (vi -r) Comments? Stephen -- Stephen J. Roznowski sjr@mimsy.umd.edu
mumble%karl@tut.cis.ohio-state.edu.UUCP (12/09/87)
sjr@mimsy.UUCP writes:
The big concern that has been expressed about
mounting this ram disk as /tmp (as opposed to /ram) is that if the
editor, etc. dies, there are no temporary files to be recovered.
(vi -r)
Use Emacs instead.
(i'm sorry, really i am, but it was just *too* easy...)
-=-
Karlrbj@icst-cmr.arpa (Root Boy Jim) (12/11/87)
It is my recollection (from the good old days of real machines with 64 or 128kb address spaces, and maybe 4meg of memory) that the real win came with having /tmp as ram, as everything wrote it's tmp files there to save memory (vi, ed, cc, mail, troff,....), and with this as a ram disk, you really won. Not necessarily. As you well know, UNIX does writes when it feels like it, and uses any available in core blocks to read from. So if a program started and finished between /etc/update's sync's, the only disk overhead would be that of creating and deleting a directory entry which is done synchronously. If you declare /tmp as a disk, you will be keeping two copies of the most recently used blocks in core. Of course, I defer to Ron Natalie's real world observation that it really does help. After all, how many invocations of the above named commands have you run in less than 30 seconds lately? Jason (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 I'm continually AMAZED at th'breathtaking effects of WIND EROSION!!
ron@topaz.rutgers.edu (Ron Natalie) (12/14/87)
....Yes, and BRL-BMD as the BRL gateway is now THE busiest host on MILNET in the last performance figures. -Ron
mike@BRL.ARPA (Mike Muuss) (12/14/87)
BRL gave a lot of business to the "BULK MOS" RF-11 emulator companies
back in the PDP-11 days. It was indeed true that the best choice
for a bulk memory system was /tmp. The second best choice was the
root itself.
This is due to the high frequency of access, and the fact that all
filesystem accesses were single block transfers (512 bytes). The
zero rotational delay on the bulk memory, plus the very high DMA rates,
helped enormously. We could sustain more than 200 1-block DMAs through
the filesystem per second off such a "drive".
Using the bulk memory for swapping helped very little. Recall that
PDP-11 UNIX allocated a contiguous area on the swap device for each
process (two areas, if pure text), so that a swap in could be
accomplished in one (or two) DMAs. Seek time didn't make much
difference. Being thorough and compiling all system programs to have
pure text helped even more. Our strategy was to use an old RK-11 on a
dedicated controller as our swap device.
As an example, the machine BRL-BMD.ARPA (now defunct) was a PDP-11/70
with 2 Mbytes of main memory, and roughly the following disk configuration:
Root: Dataram BULK CORE (non-volatile)
Swap: RK-11 drive on a dedicated controller (well, with one other drive
used occasionally for private user packs)
/tmp: Dataram BULK MOS
/usr: CDC 9762 (80 Mbyte) drive on Cachebus ("MASSBUS") via SI 9400
users: CDC 9766 (300 Mbyte) drive on Cachebus ("MASSBUS") via SI 9400
Note that this obeyed the "5 drives minimum" rule for configuring PDP-11
UNIX systems, taking it even further by having 5 controllers.
This system, running BRL/JHU UNIX, had full TCP/IP support, and could
handle 30+ users with sub-second response time for text editing in EMACS
during peak load, due to the "high performance scheduler" work (which I
reported on at the 1979 Summer USENIX Conference).
The processor, a trusty old friend purchased in 1977, is still with us,
now running BRL's LOS GATEWAY software (written by Ron Natalie, with
some assistance from the rest of ACST), and functioning as one of BRL's
primary IP gateways (as are our other 2 PDP-11/70 processors).
Ah, memories. (pun intended).
-Mike