Path: utzoo!attcan!uunet!aplcen!haven!decuac!decwrl!shelby!eos!ames!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Real disk FASTER than Ram disk
Message-ID: <136445@sun.Eng.Sun.COM>
Date: 31 May 90 19:49:21 GMT
References: <641@sibyl.eleceng.ua.OZ> <136299@sun.Eng.Sun.COM> <1990May27.210935.8564@murdoch.acc.Virginia.EDU> <3402@auspex.auspex.com> <5488@titcce.cc.titech.ac.jp>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 20

In article <5488@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>In article <3402@auspex.auspex.com>
>	guy@auspex.auspex.com (Guy Harris) writes:
>
>>No, it first showed up in 4.1.  It's more of a "RAM file system" than a
>>"RAM disk", as it plugs into the VFS interface.  It's also more of a
>>"RAM+swap space file system", as the data in the file system lives in
>>virtual memory, rather than physical memory, and can be paged out to
>>swap space. 
>
>Then, what if, when there are two processes, one is heavily using
>real memory and one is heavily performing IO to tmpfs?
>
>Isn't a large amount of real memory unnecessarily allocated to the
>latter process?

Maybe.  Maybe not.  They'll fight it out, like any other concurrent processes.
The pager will free stuff up based on reference bits.
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com