rcw@qetzal.UUCP (Robert C. White) (12/07/87)
Hello Wizards, 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. I've never seen anyone mention this, and it may be that it would require major hacking on the kernel, but you guys know best... Robert White -- //////////////////286 Moderator -- comp.unix.microport\\\\\\\\\\\\\\\\\ Email to microport@uwspan for info on the newsgroup comp.unix.microport. otherwise mail to microport@uwspan with a Subject containing one of: 386 286 Bug Source Merge or "Send Buglist" (rutgers!uwvax!uwspan!microport)
dave@spool.wisc.edu (Dave Cohrs) (12/07/87)
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? The idea is that when you add memory, you shouldn't *have* to swap. I know that when my workstation goes up to 10meg (oh where, oh where did that purchase order go?), I'm not going to be worrying about what kind of device implements /dev/swap, at least until I expand to using more than 10meg at the same time. Are there really brain-dead UNIX-like things out there that can't see all of memory? dave Dave Cohrs +1 608 262-6617 UW-Madison Computer Sciences Department dave@cs.wisc.edu ...!{harvard,ihnp4,rutgers,ucbvax}!uwvax!dave
ron@topaz.rutgers.edu (Ron Natalie) (12/07/87)
This is a joke, right? If you had more memory you'd use it for virtual memory? Actually we had so DataRAM bulk RAM boxes. These looked like exteremely fast disk drives (the machine already had maximum physical memory). Performance tests showed that these boxes increased performance most when used for /tmp and / (in that order). -Ron
physh@unicom.UUCP (Jon 'Quality in - Quantity out' Foreman) (12/08/87)
In article <712@qetzal.UUCP> rcw@qetzal.UUCP (Robert C. White) writes: >Hello Wizards, > >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. > >I've never seen anyone mention this, and it may be that it would >require major hacking on the kernel, but you guys know best... > >Robert White I would think that if you could put more memory in the machine, you'd use it for main memory, which would also decrease swapping and at the same time allow larger/more programs to run. If memory got big enough, you could do away with the swap space entirely (but this will never happen, someone will always come up with a bigger program.) I also question whether it is more effient to have the CPU spend time copying blocks into and out of the swap space when a DMA disk controller could do it with no CPU overhead, thus letting any runable processes run. Ram disks really only win big in single tasking operating systems because you have to wait for the disk controller anyway, and with a ram disk, you have to wait less time. In timesharing, you use the time swapping one person out to run someone else. A friend of mine had an idea for a product which was a hugh array of cheap slow memory which emulated a disk drive, and even would have come in a disk drive case. The object here was that there would be no latency, and you could still hang it on a DMA disk controller. Could this be what you're really looking for? -- {ucbvax,hoptoad}!\ ~~~~~~~\~~~ That's spelled {lll-lcc,hplabs}!well!unicom!physh Jon }() "physh" and {ptsfa,dual}!/ / pronounced "fish".
blarson@skat.usc.edu (Bob Larson) (12/09/87)
In article <213@unicom.UUCP> physh@unicom.UUCP (Jon 'Quality in - Quantity out' Foreman) writes: > A friend of mine had an idea for a product which was a hugh >array of cheap slow memory which emulated a disk drive, and even would >have come in a disk drive case. The object here was that there would >be no latency, and you could still hang it on a DMA disk controller. >Could this be what you're really looking for? Several companies already make these. We are currently testing one (megaram?) with an esmd interface on one of our Primes. Transfer time is the same as a real disk, where it wins is seek time. As others have said, using such a device for swaping is mainly a win if you are already at maximum memory on your system. Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (12/10/87)
In article <712@qetzal.UUCP> rcw@qetzal.UUCP (Robert C. White) writes: | Hello Wizards, | | 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 On a number of small system there are "classes" of memory which have different access times. While the people with big bucks will undoubtedly tell you to buy all new and fast memory, In many cases you'd rather not have the CPU running in slow memory, but it's faster than disk for swap/page operation. I hope you get an answer, as opposed to a buch of people telling you that you don't want to do it. I have another 4MB of slow memory, and I would love to be able to use it for disk, and for storing frequently used files. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
shap@bunker.UUCP (Joseph D. Shapiro) (12/10/87)
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? -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Joe Shapiro "My other car is a turbo... Bunker Ramo Olivetti too." {decvax,yale,philabs,oliveb}!bunker!shap
nwh@hrc63.co.uk (Nigel Holder Marconi) (12/11/87)
I have just added some extra memory to a Sun 3. Unfortunately, it did not increase the usable amount of virtual memory. I have been informed (not by Sun I hasten to add), that 4.x will only allocate memory up to the disk swap space size. Adding more memory will speed things up but will not increase your total usable virtual memory size (this is achieved by increasing the swap space). I was also informed that system V does not inforce this type of restriction. Nigel Holder UK JANET: yf21@uk.co.gec-mrc.u ARPA: yf21%u.gec-mrc.co.uk@ucl-cs
allbery@ncoast.UUCP (Brandon Allbery) (12/12/87)
As quoted from <4821@spool.wisc.edu> by dave@spool.wisc.edu (Dave Cohrs): +--------------- | 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? | | The idea is that when you add memory, you shouldn't *have* to swap. I | know that when my workstation goes up to 10meg (oh where, oh where did | that purchase order go?), I'm not going to be worrying about what kind | of device implements /dev/swap, at least until I expand to using more | than 10meg at the same time. Are there really brain-dead UNIX-like | things out there that can't see all of memory? +--------------- Tandy 16/6000 series can only address 1MB presently due to a brain-damaged MMU (recent hardware mod, hopefully soon to be released, raises that to 4MB at the expense of having larger memory segments); however, it's capable of *physical* addressing 7MB. So the Wizard of TRS (aka Bob Snapp) sells a 6MB RAM board and ramdisk software for it.... -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
rbl@nitrex.UUCP ( Dr. Robin Lake ) (12/12/87)
In article <712@qetzal.UUCP> rcw@qetzal.UUCP (Robert C. White) writes: >Hello Wizards, > >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. About 10 years ago, I was involved with the design of a "solid-state disk" --- a ram disk that looked like a fixed-head disk for PDP-11 Unibus machines. A graduate student of mine did his Ph.D. dissertation on the performance of UNIX with such a box. (Sugit Kumar, Case Western Reserve University). Bottom line was that you want TWO such "ramdisks", one for /tmp or /usr/tmp and one for the commonly used programs (/bin, /usr/bin). The only shortcoming is that the device drivers and the I/O strategies of the kernel consume relatively huge amounts of time per "disk" access. The result is that a solid-state device (17,000 times faster transfer rate than a rotating disk) only performs 10 to 50 times better. Nonetheless, watch for significant new computer architectures from the 3-letter computer vendors which take advantage of more ram memory than you might have ever believed would fit in a box! Exciting times ahead.... Rob Lake BP America R&D (ex-Principal Scientist, Monolithic Systems Corp - mfgr. of "Extended Memory Unit" ) decvax!mandrill!nitrex!rbl 216-581-5976 -- Rob Lake {decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/13/87)
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? You forgot the smiley-face :-)
ron@topaz.rutgers.edu (Ron Natalie) (12/14/87)
Say what? On PDP-11's UNIBUS attached disks can not possilby have 17,000 times the transfer rate of conventional disks. The whole bandwidth of the bus is 2.2MB per second in the best of cases. Most drives even in days gone by could approach a 1MB/s. What you don't have is the seek latency. -Ron
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (12/14/87)
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? The idea is to get all the memory you can and put the file systems that you use for small, temporary file creation in memory. Not /dev/swap, as enough memory means never having to say you're swapping. In article <10796@brl-adm.ARPA>, mike@BRL.ARPA (Mike Muuss) writes: > 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 (root as RAM being good) was really a problem with the V7 kernel. Since the V7 kernel immediately discarded all text segments and inodes (until Mike Karels added shared text segments to 2.9BSD, whereupon it discarded them after the last reference disappeared) it helped to put the program in a RAM disk. The real fix was to teach the kernel to do LRU cacheing on the text and inodes. Once that was done, we found that, on PDP's with 4MB of memory and student type loads, you can't get enough people on the machine to use all of memory and nothing ever swaps. Keith Bostic ARPA: bostic@okeeffe.berkeley.edu UUCP: ucbvax!bostic or seismo!keith
asgard@cpro.UUCP (J.R. Stoner) (12/14/87)
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.
ron@topaz.rutgers.edu (Ron Natalie) (12/15/87)
Kieth, I believe you are wrong here. Text segments in V7 stayed in swap until the last referenced disappeared (in the normal case) or forever, if you had the ISVTX (sticky) bit set. You are right about the rest. -Ron
seb022@tijc02.UUCP (Scott Bemis ) (12/16/87)
> Hello Wizards, > > 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 > > I've never seen anyone mention this, and it may be that it would > require major hacking on the kernel, but you guys know best... > I currently have "two ram disks" on a VAX 8600 using the AT&T UNIX V Release 2.0 Version 2. I currently have /tmp and /usr/tmp in these ram disks. Since the VAX 8600 has 32 megabytes of memory, it rarely ever swaps. So, the swap area is out on disk. I have never tried putting swap in memory. Uniq Digital Technologies INC, 28 South Water Street, Batavia, IL 60510, telephone; (312) 879-1566 gave me the device driver to do this.
rbl@nitrex.UUCP ( Dr. Robin Lake ) (12/16/87)
In article <17013@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >Say what? On PDP-11's UNIBUS attached disks can not possilby have >17,000 times the transfer rate of conventional disks. The whole >bandwidth of the bus is 2.2MB per second in the best of cases. Most >drives even in days gone by could approach a 1MB/s. What you don't >have is the seek latency. > >-Ron It depends upon what the transfer rate and interleave factor of the "conventional disks" are. The solid-state RF-11/RS-11 disk equivalent was invented in the summer of 1970. There were few head-per-track disks from DEC at that time (as I recall, the one adapted from the PDP-8 and PDP-12 lines was 32Kbyte or 64K bytes) and the low bit density led to slow transfer rates. So.... it's all a question of the denominator. The controller on the Monolithic Systems "EMU" (Extended Memory Unit) was capable of doing multiple DMA disk transfers in a single bus request, which pushed the transfer rate right close to the Unibus limit. I've forgotten what we got for the peak transfer rate, but I vaguely remember a hair above 2 Mb/sec. (8 times 256 K words in a data acquisition application using a dual-port "EMU"). Rob Lake -- Rob Lake {decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl
peer@prle1.UUCP (Tom van Peer) (12/24/87)
In article <183@tijc02.UUCP> seb022@tijc02.UUCP (Scott Bemis ) writes: > Hello Wizards, > > 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 > > I've never seen anyone mention this, and it may be that it would > require major hacking on the kernel, but you guys know best... > Why bother to swap from ram to ram ? If you have extra memory I think you should use it as primary and not as secondary memory. It's a different case off course if you want to use ram as an extra disk with a file system on it, then you have an extra archieving function. But in the case of /dev/swap you're only moving pieces of program back and forth, only to relieve your primary memory, so why would you want to do that entirely in ram ? Tom van Peer. Philips Research Labs. Eindhoven. E-mail: mcvax!prle!TvanPeer. phone: +31 - 40 - 743796