Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!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: <5756@titcce.cc.titech.ac.jp>
Date: 3 Jul 90 07:19:42 GMT
References: <499@garth.UUCP> <5660@titcce.cc.titech.ac.jp> <137770@sun.Eng.Sun.COM> <1990Jun26.185232.3565@utzoo.uucp> <138208@sun.Eng.Sun.COM>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 45

In article <138208@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:

>Subject: Re: Mixing paging and IO is inefficient (was Re:  Compiler partions)

So, perhaps, you are talking about the topic of mixing paging and IO.

Or, maybe, you are still confused.

>I said:
>>>... The synchronous
>>>nature of certain file system writes are *required* for file system
>>>reliability.  Just so you understand: consider what happens when you create
>>>a file.  You allocate an inode and add a directory entry.  Think about the
>>>steps and the order of operations.  If you do it wrong, and the system
>>>crashes, you leave dangling pointers...

As several people pointed out, that is not a problem on ordinary UNIX.
Do you want to say it will be a problem if paging and IO is overly mixed?

Then, though I can't understand why, it is an another defect of mixing.

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

Then, though I can't understand why, it is an another defect of mixing.

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.

>Just don't believe everything that is implied in Ousterhout's paper.
>You can put in his file system and maybe that will make you feel
>better, but your program won't run much faster, if at all.

If you are using slow CPU, most program is CPU bound, so, they won't
run much faster.

So, use fast CPU, and then, may program will then IO bound.

					Masataka Ohta