Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!caip!clyde!burl!ulysses!bellcore!whuxcc!judah
From: judah@whuxcc.UUCP (Judah Greenblatt)
Newsgroups: net.unix-wizards
Subject: Re: RAM disk vs paging + buffer cache
Message-ID: <240@whuxcc.UUCP>
Date: Mon, 11-Aug-86 20:13:30 EDT
Article-I.D.: whuxcc.240
Posted: Mon Aug 11 20:13:30 1986
Date-Received: Tue, 12-Aug-86 21:59:02 EDT
References: <514@opus.nbires.UUCP>
Organization: Bell Comm. Rsrch., Morristown, NJ
Lines: 56

> Some recent discussions in unix-wizards and here at work set me to thinking
> about why one would want a RAM disk as a general sort of feature.  ("RAM
> disk" refers to using a fixed part of main memory as if it were a disk-like
> device.)

I was involved in developing ram-disk drivers for several unix systems
in an attempt to speed up a large application.  During the work we
discovered the following useful tidbits:

- file systems like /tmp, with large numbers of short-lived files,
  generate an inordinate amount of physical I/O activity.  I'm not
  sure why, but it seems that the following sequence generates several
  physical I/O operations, even when the buffer-cache is empty:
	- create a file
	- write 1 block of data
	- close it
	- open it again
	- read the data
	- close it again
	- unlink the file
   In the face of thousands of programs which perform this sequence
   hundreds of times a minute, putting /tmp in ram is a big win.

-  The free-list is not an efficient cache of program text.
   In a machine with 20,000 free pages, no more than 2000 of which
   were ever in use at once, the 'hit ratio' of the free list was
   measured at under 80%, while the 2000 block buffers had a hit
   ratio over 95%.

-  While program text can be reclaimed from the free list, initialized
   data pages cannot.  As the page fault system in 4.2BSD bypasses
   the block buffers when faulting in initialized data pages,
   there is NO buffering of such pages, and every page fault generates
   a physical I/O operation.  When running lots of short-lived programs
   which have a lot of initialized data, it may pay to try to put
   the entire file system containing your programs into ram!

-  Note that all of the above is talking about short-lived files and
   quick-running, tiny programs.  Unix already seems to handle the
   big stuff well enough.  (Well, almost well enough.  You do keep
   your large files one per raw disk partition, don't you? :-)

-  To play these games requires a LOT of memory.  Don't even think
   of allocating less than 1 MB to a ram disk.  If you will be putting
   programs into core, expect to use 10 MB or more.  As you will also
   want 1000 or more block buffers, and probably need to support 100+
   users, you're going to need at least 32 MB of ram.

-  One thought on why you might not want to let the block buffers
   do all the work: can you imagine what a 'sync' would
   cost on a system with 20,000 block buffers?
-- 
Judah Greenblatt		"Backward into the Future!"
Bell Communications Research	uucp: {bellcore,infopro,ihnp4}!whuxcc!judah
Morristown, New Jersey, USA	arpa: whuxcc!judah@mouton.com
  * Opinions expressed are my own, and not those of the management.