mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/25/90)
In article <637@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >If the 386 is a real computer, what use is a ram disk? Increase the >disk block cache to 4MB. That should be just as fast(*) and much more >flexible. Ram disk is actually effective when many sync writes are issued, such as compilation of many small files. But, even in such a case, there is a better solution than memory disk approach. See my paper of the next USENIX. >(*) It might even be faster. Yes. Masataka Ohta mohta@cc.titech.ac.jp
ian@sibyl.eleceng.ua.OZ (Ian Dall) (05/27/90)
In article <5461@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >In article <637@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: > >>If the 386 is a real computer, what use is a ram disk? Increase the >>disk block cache to 4MB. That should be just as fast(*) and much more >>flexible. > >Ram disk is actually effective when many sync writes are issued, such as >compilation of many small files. Can you elaborate? What are these sync writes? If they consist of an fsync or whatever after every write (or after each process completes), then why are the fsyncs being done in the firstplace. If the compiler is broken, fix it. I still see no reason to add a RAM disk. I am, however, genuinely interested though if there is any reason I can't think of for putting a ram disk on a machine with a "proper" operating system. I kind of get the impression that people offer unix ram disk drivers to ex messy dos users because that is easier and more profitable than explaining to them that they don't need one! >But, even in such a case, there is a better solution than memory disk >approach. See my paper of the next USENIX. Hmmm. I won't be going, but it could be worth finding it in the proceedings... -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
lm@snafu.Sun.COM (Larry McVoy) (05/28/90)
In article <641@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >>Ram disk is actually effective when many sync writes are issued, such as >>compilation of many small files. > >Can you elaborate? What are these sync writes? If they consist of an >fsync or whatever after every write (or after each process completes), >then why are the fsyncs being done in the firstplace. If the compiler >is broken, fix it. I still see no reason to add a RAM disk. Directory updates are synchronous. Why they are is a topic for an OS course, not comp.arch - I'd be happy to explain offline. As a side note: check out Sun's tmpfs. It's a variable sized ram disk that doesn't do the extra copy. I think it solves most of the problems that were discussed in this thread. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
gsh7w@astsun8.astro.Virginia.EDU (Greg S. Hennessy) (05/28/90)
In article <136299@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
#As a side note: check out Sun's tmpfs. It's a variable sized ram disk that
#doesn't do the extra copy.
I can't find anything about it in the man pages. Is it available on
4.0?
--
-Greg Hennessy, University of Virginia
USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA
Internet: gsh7w@virginia.edu
UUCP: ...!uunet!virginia!gsh7wguy@auspex.auspex.com (Guy Harris) (05/29/90)
>#As a side note: check out Sun's tmpfs. It's a variable sized ram disk that >#doesn't do the extra copy. > >I can't find anything about it in the man pages. Is it available on >4.0? 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.
casey@gauss.llnl.gov (Casey Leedom) (05/31/90)
It's trivial to avoid the extra copy. You just add an extra flag to the buffer header that indicates whether the header points at a buffer pool block or a block on the ram disk. A read of a ram disk block not in the buffer cache just caused a buffer header to be pointed at the ram disk block and the special flag to be set. A flush of a buffer cache block just caused the buffer header to be repointed back into the buffer cache and the flag to be cleared. We did this for 2.10BSD and it worked very nicely. A better solution (as has been pointed out) is to allow for memory resident file systems that are only written out to backing disk when space is needed. This works well for temporary file systems like /tmp where a compiler pass may create a temporary files and a later pass reads and deletes the file. If there's enough space in memory, the files blocks should never hit real disk. Casey
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/31/90)
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? Masataka Ohta
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (05/31/90)
In article <60196@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: > It's trivial to avoid the extra copy. Maybe. But, writing a memory disk device driver is already non-trivial. Moreover, a memory disk has several limitations including its maximum size. > A better solution (as has been pointed out) is to allow for memory >resident file systems that are only written out to backing disk when >space is needed. That is what I have described in a paper titled: A fast /tmp file system by delay mount option Masataka Ohta
lm@snafu.Sun.COM (Larry McVoy) (06/01/90)
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
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (06/01/90)
In article <5490@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
? But, writing a memory disk device driver is already non-trivial.
I beg to differ on this point. I think it depends highly on the involved
operating system. I've written many device drivers for a real-time
operating system called ERM System and the ram disk driver was the most
easy one to write. Others were real disk drivers, centronics, RS232,
Ethernet, IEEE-bus.
? Moreover, a memory disk has several limitations including its maximum size.
Just like a normal physical disk. No distinction here.
--
Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl
Philips Information Systems UUCP ...!mcsun!philapd!dolf
Dept. BS Software, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands
read: error in reading .signaturefouts@bozeman.ingr.com (Martin Fouts) (06/08/90)
In article <5490@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > It's trivial to avoid the extra copy. Maybe. But, writing a memory disk device driver is already non-trivial. Moreover, a memory disk has several limitations including its maximum size. > A better solution (as has been pointed out) is to allow for memory >resident file systems that are only written out to backing disk when >space is needed. That is what I have described in a paper titled: A fast /tmp file system by delay mount option Excuse me for disagreeing, but replacing /tmp with a file system that gets paged isn't a good solution. What you are doing here is working around the lack of advance in the underlying software. The compiler is still writing to /tmp because it isn't managing its own address space effectively in a virtual memory environment. Direct mapping files into the compiler address space and paging from that is much more effective than using a second order paging for a "file system" ala /tmp. -- Martin Fouts UUCP: ...!pyramid!garth!fouts ARPA: apd!fouts@ingr.com PHONE: (415) 852-2310 FAX: (415) 856-9224 MAIL: 2400 Geng Road, Palo Alto, CA, 94303 If you can find an opinion in my posting, please let me know. I don't have opinions, only misconceptions.
csimmons@jewel.oracle.com (Charles Simmons) (06/08/90)
In article <431@garth.UUCP>, fouts@bozeman.ingr.com (Martin Fouts) writes: > From: fouts@bozeman.ingr.com (Martin Fouts) > Subject: Re: Real disk FASTER than Ram disk > Date: 7 Jun 90 18:46:14 GMT > > In article <5490@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > > > A better solution (as has been pointed out) is to allow for memory > >resident file systems that are only written out to backing disk when > >space is needed. > > That is what I have described in a paper titled: > > A fast /tmp file system by delay mount option > > Excuse me for disagreeing, but replacing /tmp with a file system that > gets paged isn't a good solution. What you are doing here is working > around the lack of advance in the underlying software. The compiler > is still writing to /tmp because it isn't managing its own address > space effectively in a virtual memory environment. Direct mapping > files into the compiler address space and paging from that is much > more effective than using a second order paging for a "file system" > ala /tmp. > > -- > Martin Fouts Er, um, it's not clear that virtual memory is the most desirable abstraction here. The compiler uses files in /tmp in order to communicate results from one pass of the compiler to the next. On modern architechtures (i.e. massively parallel processors), we would probably want to run 'cpp', 'cc', 'as', 'ld', and possibly a few optimization passes in parallel with something vaguely resembling a pipe connecting the processes together and holding various translated versions of the source code. The compilation process is my favorite example of a computational task that can be easily parallized by making use of a pipeline. -- Chuck
mohta@necom830.cc.titech.ac.jp (Masataka Ohta) (06/10/90)
In article <431@garth.UUCP> fouts@bozeman.ingr.com (Martin Fouts) writes: >Excuse me for disagreeing, but replacing /tmp with a file system that >gets paged isn't a good solution. What you are doing here is working >around the lack of advance in the underlying software. The compiler >is still writing to /tmp because it isn't managing its own address >space effectively in a virtual memory environment. Compiler is using intermediate files, mostly because its development is much easier by separating the compilation process into multiple phases. Correctness is much important than compilation speed. >Direct mapping >files into the compiler address space and paging from that is much >more effective than using a second order paging for a "file system" >ala /tmp. No. On UNIX, when delayed write is used, memory access is not so much faster than IO. Moreover, according to your policy, compilers shouldn't produce intermediate file even into its address space. Just compile in a single phase. BTW, using memory instead of disk files is real memroy ineffecient way. IO is IO and has its own property. For example, most IO is done with sequential access pattern and dose not require so much real memory for buffering. On the other hand, most memory access is done with LRU access pattern and allocating much real memory will improve performance. But, overly mixed IO and swap will fail to utilize such special properties of IO. Masataka Ohta