Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!lll-winken!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: Mixing paging and IO is inefficient (was Re:  Compiler partions)
Message-ID: <5782@titcce.cc.titech.ac.jp>
Date: 5 Jul 90 11:22:40 GMT
References: <5660@titcce.cc.titech.ac.jp> <3830011@hpcupt1.HP.COM>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 32

In article <3830011@hpcupt1.HP.COM>
	renglish@hpcupt1.HP.COM (Robert English) writes:

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

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

Yes. Especially when you don't have enough knowledge.

>Maybe Sun's file
>system is written well enough that tmpfs is no longer useless.  There
>are certainly many techniques that would allow that.

You should understand when memory disk brings performance
improvement. Do you know what is sync write?

>Maybe Sun's
>compilers make copious use of virtual memory and don't use temporary
>files at all.

Kernel recompilation was chosen by SUN as a benchmark of tmpfs.
Why? Of course, compilation process heavily use /tmp.

						Masataka Ohta