Semi-conductor Disk for VAX

tjt at kobold.UUCP tjt at kobold.UUCP
Tue Jan 10 07:13:50 AEST 1984


The reason *why* system performance using a good disk is better than
using main memory as a pseudo-disk is that a DMA disk controller can
transfer data at the same time your processor is doing something useful
(i.e. executing user code, or some more directly useful part of the
system code, such as traversing a path name for a file open).  Using
main memory as a psuedo-disk requires that your processor copy data
back and forth.

On the other hand, a semi-conductor disk also has a controller that
will copy data at the same time a program is executing.  Mike Muuss
<mike at brl-vgr> points out that buying more main memory is a better (and
cheaper?) way of improving your swapping/paging performance since it
greatly decreases the amount of paging you do rather than making it
slightly faster.

Mike goes on to point out that using a semiconductor disk may make
sense for temporary files (i.e. /tmp) since "... no amount of physical
memory devoted to the UNIX buffer cache is likely to be able to cache
the whole thing."  While this is true the way memory and I/O buffers
are currently managed in UNIX (i.e. 4BSD), it is not necessarily true.
There is not good reason why the system should not take over all of
physical memory for I/O bufferring if there is no other demand for the
memory.  This is easier in a system such as Multics which already has a
uniform view of memory, but should not be terribly difficult to add to
UNIX.  Basically, all that is required is to use a common data
structure to keep track of what physical memory is used for, rather
than reserving one pool of physical memory for I/O buffers, and another
for programs.  One way of doing this would be to add a page type (e.g.
CIO) to the cmap structure.  The pageout demon could free this page by
calling bwrite.  You may still to limit the maximum number of pages
used by I/O buffers though if you didn't want to deal with dynamically
allocating and freeing struct buf's.
-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt   (617) 692-6200



More information about the Comp.unix mailing list