Path: utzoo!attcan!uunet!samsung!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!hplabs!hpda!hpcupt1!renglish
From: renglish@hpcupt1.HP.COM (Robert English)
Newsgroups: comp.arch
Subject: Re: Mixing paging and IO is inefficient (was Re:  Compiler partions)
Message-ID: <3830011@hpcupt1.HP.COM>
Date: 4 Jul 90 00:31:14 GMT
References: <5660@titcce.cc.titech.ac.jp>
Organization: Hewlett Packard, Cupertino
Lines: 29

> / mohta@necom830.cc.titech.ac.jp (Masataka Ohta) / 12:19 am  Jul  3, 1990 /

> >Don't believe me, huh?  Well, I don't entirely either.  Here's the deal:
> >things like compiles are not bound by the file system.  A coworker was
> >writing up a paper on tmpfs recently and benchmarked a kernel build
> >with /tmp over tmpfs vs /tmp over ufs.  It came out to 30 seconds 
> >difference.  Over 45 minutes.  Big deal.

> Do you want to say SUN's tmpfs is useless because of mixed IO and paging?...

> By the way, on an ordinary UNIX with a state-of-the-art CPU (say 20MHz
> R3000), delayed (thus fast) /tmp file system brings more than 20%
> improvement for the performance of a kernel recomlilation.

There are lots of interpretations possible here.  Maybe Sun's file
system is written well enough that tmpfs is no longer useless.  There
are certainly many techniques that would allow that.  Maybe Sun's
compilers make copious use of virtual memory and don't use temporary
files at all.

Maybe the 20% kernel compilation improvement on the R2000 is not
available on Suns because it's already been obtained through other
mechanisms.  That doesn't mean that tmpfs is not useful for other
applications, nor does it mean that a delayed-write /tmp is not useful.
By itself, it doesn't mean much more than "tmpfs doesn't help
compilation."

--bob--
renglish@hpda