Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!nbires!rcd
From: rcd@nbires.UUCP (Dick Dunn)
Newsgroups: net.unix-wizards
Subject: RAM disk vs paging + buffer cache
Message-ID: <514@opus.nbires.UUCP>
Date: Mon, 11-Aug-86 03:29:23 EDT
Article-I.D.: opus.514
Posted: Mon Aug 11 03:29:23 1986
Date-Received: Tue, 12-Aug-86 14:17:24 EDT
Organization: NBI,Inc, Boulder CO
Lines: 57

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.)

First, about the idea of a RAM disk:  It's certainly simple to implement;
if you can understand the basics of a device driver and you have /dev/mem
or something like it, you're 90% of the way there.

A RAM disk makes sense for special problems where what you're really doing
is making use of main memory for something peculiar to your application.

What I DON'T see is why you would want to use a RAM disk (in UNIX) for
things like frequently-used files or programs.  Consider what you've got in
a paging system like 4.2:  Frequently-used programs will have their pages
dragged into memory where they will stay as long as they are in demand.
Frequently-used files will have their most used blocks left in the buffer
cache.  It seems as if what goes on with page reclamation and the buffer
cache is really "RAM disk" behavior with dynamic adaptation to what is most
needed, and that this ought to be able to out-perform any static allocation
of information to a RAM disk device.

There are a couple of holes in this line of thinking.  First, the number of
buffers is normally fixed at startup; this means that there is no way to
make a tradeoff between memory committed to i/o and to paging.  Second, the
algorithms used to manage pages and buffer cache may not, in fact, retain
commonly used information as well as if retention were done explicitly.

The latter problem is easily answered:  First, the strategies for managing
the cache and pages can always be improved once it is known that they have
particular deficiencies.  Second, there is a balance in that explicit
retention may work better at a particular time but it is not adaptive.

The former problem suggests that one avenue to explore in performance
improvement for UNIX would be to let the buffer cache change size in
response to changing need.  It just moves the analysis up one level:
Instead of LRU on disk blocks and LRU on process-image pages, why not LRU
on the whole mess.  There's a simplification lurking here--after all, the
pages of images represent disk blocks too.  Has anyone tried fiddling with
UNIX either to make the buffer cache size adaptive or to unify page
management and buffer caching?  If you made the buffer cache size adaptive
but didn't unify the paging and buffer systems, would you get into some
sort of interference between the two algorithms (e.g., due to lack or
excess of hysteresis)?

Consider /tmp as a case where the RAM disk might do particularly well...
what (if anything) keeps the buffer cache from performing as well as a RAM
disk in this case?  If there is some significant difference in performance
now, can it be fixed?

What generally-useful features does a RAM disk have that I didn't
consider?

Comments, please.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...If you get confused just listen to the music play...