RAM disk.

[Masataka Ohta]

In article <143190 at sun.Eng.Sun.COM> lm at slovax.Sun.COM (Larry McVoy) writes:

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

>This is true in SunOS 4.1, not true in SunOS 4.1.1.  There was a bug,

If you know what is responsibility, you should post that to comp.arch.

>My measurements of kernel builds has shown a 20% improvement in wall
>clock time on an otherwise idle system.

That is what I already observed with delay option (delay option is
a very simple and better replacement of RAM disk or tmpfs, see my
paper in the proceedings of 1990 summer USENIX conference).

>Tests like "time dd if=/dev/zero of=/tmp/XXX count=1000" showed data
>rate changing from 300KB / sec to 5MB / sec on a SS1 (if you do the math
>a SS1 can't bcopy much faster than that).

And you can observe the same 5MB/sec rate even on ordinary files, if
you are using a SANE UNIX.

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

>2X as slow is correct.  The reasoning is incorrect.  Tmpfs is better
>than a ram disk because it avoids an extra copy two times.

READ WHAT I POST.

>>If you do large amount of IO to /tmp, with simple-minded memory disk,
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am not saying anything about tmpfs here.

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

>Bullsh*t.  Tmpfs is orders of magnitude faster than a disk.  

Of course, you KNOW fgrep is faster than grep.

I miss comp.unix.wizards.

See the assumption:

>>If you do large amount of IO to /tmp,
            ^^^^^^^^^^^^^^^^^^

If you know what is buffer cache, you can understand why tmpfs is only
as fast as ordinary disk file.

						Masataka Ohta