Xref: utzoo comp.unix.admin:264 comp.unix.internals:430
Path: utzoo!attcan!uunet!world!decwrl!apple!netcom!amdcad!sun!slovax!lm
From: lm@slovax.Sun.COM (Larry McVoy)
Newsgroups: comp.unix.admin,comp.unix.internals
Subject: Re: RAM disk.
Message-ID: <143190@sun.Eng.Sun.COM>
Date: 30 Sep 90 07:08:40 GMT
References: <900908.7074@franklin.com> <1990Sep12.084002.5575@hq.demos.su> <1223@tardis.Tymnet.COM> <1990Sep13.002300.15266@mlb.semi.harris.com> <6167@titcce.cc.titech.ac.jp>
Sender: news@sun.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 49

In article <6167@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>In article <1990Sep13.002300.15266@mlb.semi.harris.com>
>	del@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.

This is true in SunOS 4.1, not true in SunOS 4.1.1.  There was a bug,
a rather silly bug, the made write performance to tmpfs about
the same as ufs.  (For those who care, in the write case, if you are
doing a partial page, you have to read in the page before writing over
the part that the user sent down.  If you are writing a whole page
there is no need to fault in page from disk; you're overwriting all
of it.  Tmpfs didn't think to do this optimization; so performance
was limited by how fast one can fault in pages from the swap device.)

My measurements of kernel builds has shown a 20% improvement in wall
clock time on an otherwise idle system.  Test was a build of a 
GENERIC kernel (i.e., everything) and the only difference was 
/tmp was tmpfs instead of UFS.

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

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

2X as slow is correct.  The reasoning is incorrect.  Tmpfs is better
than a ram disk because it avoids an extra copy two times.  It copies
the data from user to kernel but not from kernel to ramdisk.  If you
think about that's two less copies.  Think hard.

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

>						Masataka Ohta
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com