Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!public!eeh From: eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <574@public.BTR.COM> Date: 6 Oct 90 18:10:00 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <1990Sep27.124036.9866@msuinfo.cl.msu.edu> <1990Sep27.154312.21380@msuinfo.cl.msu.edu> Organization: BTR Public Access UNIX, MtnView CA, Contact: cs@btr.com 415-966-1429 Lines: 64 In article eachus@linus.mitre.org (Robert I. Eachus) writes: > A couple of comments on this issue. First don't use T: for >paging. This has come to be the place to put small temporary files, >and most users have it assigned to RAM: or some other ram disk. The >best idea would be to use a new name such as SWAP: Sorry, too late. WordPerfect already uses T: for its storage. > Second, I like the library idea, and doing it right should be >easy and highly portable. Create a swap.device -- actually two, one >for machines with MMU's and one for machines without. Programs would >be would be guaranteed that the most recently seeked to page was >valid. The swap device would have to write all pages opened >read/write when it was necessary to flush them on the non-MMU version, >but could check the hardware flags on the MMU version. Software VM would require a great deal of locking/unlocking code to make certain that the data you are accessing is in memory when its needed and can be purged when its not. If the same program were to run on a machine with an MMU, you would still be executing all of that code, so the MMU would buy you nothing. The overhead involved in locking and unlocking chunks of data would greatly slow execution especially if it involved library or function calls. Macros would be best. Pointers would not be valid unless VM had its own address space. You would receive about the same benefit as using fread()/fwrite()/ lseek() but your buffers would eventually take up all free RAM. The only advantage would be the ability to control the size of the resulting file. This is not a general purpose solution for running programs with more data than available RAM. I think we ought to deal with S/W VM and H/W VM as two separate issues. H/W VM is a general solution to times when programs need more memory than is available. On startup, a VM program could link into the VM manager and ask for VM. This task would then receive its own MMU table and could request whatever memory it needed. AllocMem() would need to be SetFunction()ed to provide the necessary information to the VM manager (when swap pages to disk.) MEMF_PUBLIC would become very important. (Imagine your message port being swapped out! 8^) Internally, VM would be completely transparent, pointer would work, etc. but communicating with other tasks could be difficult due to different address spaces. S/W VM would likely be very application dependent. A system that works well for an editor would likely not work for a draw program where you want to swap out individual or collections of objects. On a side note, assuming that a system using systems level VM with one address space was implemented, and swapping was only allowed in Fast RAM, is there any easy method to determine which portions of RAM are occupied by non-swappable code like interrupt servers? It would be very embarbassing to discover the VM handler had swapped out an interrupt server code or data block and the system came crashing down. A second interesting situation would occur if the swap space were assigned to a RAM drive or virtual disk that was running under VM... >-- > Robert I. Eachus ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I know what I'm doing." - Sledge Hammer =========================================================================