RAM disk.

[Masataka Ohta]

In article <1990Sep13.002300.15266 at mlb.semi.harris.com>
	del at thrush.mlb.semi.harris.com (Don Lewis) writes:

>Does anyone have a feel for the relative performance of Sun's tmpfs versus
>a 4.2 filesystem?

Few monthes ago, in comp.arch, someone in Sun posted the result of
measurement that tmpfs won't improve performance of whole kernel
recompilation.

>I have an application that uses a lot of temporary
>file space.  After it is finished thrashing about with the scratch files
>it builds a large data structure in memory.  The amount of swap space
>and the amount of scratch file space consumed at one time are someone
>complementary.

There is positive correlation between amount of swap space and amount
of temporary file necessary for a process. Moreover, they are
often necessary at the same time.

That is, if you output something large to file, you almost certainly have
a copy of it in memory, and vice versa.

>Widhout using tmpfs, I need both big swap and big /tmp.

So, even with tmpfs, you need twice as big swap.

>The issue is what is the performance when simultaneously reading and
>writing several large files (and possibly significant paging as well)
>using tmpfs versus the same operations using the 4.2 filesystem.

If you do large amount of IO to /tmp, with simple-minded memory disk,
it is about TWICE AS SLOW AS ordinary disk file system.

The reason is that memory disk can't do async write. Data is copied
from user space to buffer cache and then to memory disk. With ordinary
disk, data is only copied to buffer cache.

If you use elaborated and complicated memory disk, it can be only as
slow as ordinary disk, but not faster.

						Masataka Ohta