Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory / doable 1.4 request
Message-ID: <8905132040.AA27524@postgres.Berkeley.EDU>
Date: 13 May 89 20:40:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 69


	Refering back to my first article, I have a couple more implementation
ideas:

	(1) Since a distinction between real and virtual memory exists, the
	    user should be able to set how much real memory the virtual memory
	    will be mapped to.  For example, if we have 2MB of ram and a 
	    process that is using 20MB of virtual memory, we do not want to
	    use all 2MB for VM simply because many programs will still need
	    to allocate non-virtual memory.

	    So, for example, the user (read: s:startup-sequence) would tell
	    the system to use X amount of MB or X% of real memory for 
	    virtual memory.

	    The beauty of it all is that no matter how little or how much you
	    specify, no program using VM will know the difference.  The more
	    you reserve, the less paging will have to go on.

	(2) The Maximum amount of virtual memory in the system can be 
	    implemented in two ways.  I would like to say something like this
	    in s:startup-sequence :

		enablevm 30% hdv:virtual-memory 20M

	    Turn on virtual memory, reserve 30% of real memory for virtual
	    memory, use the file hdv:virtual-memory to page to and set the
	    maximum amount of VM to 20MB.  There are three possible ways to
	    implement this:

	    P.S. for those of you who are not familar with VM techniques, note
	    that real memory isn't actually mapped until you reference the VM
	    page.  real memory is NOT mapped at allocation.

	    (A) Open(file,1006) and write 20MB of zero's (or garbage), map 20MB
		worth of memory via the MMU, and then just treat the memory
		like almost-normal AllocMem'd memory... you can even use the
		same allocation algorithm!

		* my first choice, extremely simple.

	    (B) Open(file,1006) and write nothing yet.  Assume you will be 
		able to extend the file as needed to 20MB, map 20MB worth of
		memory via the MMU and use a slightly modified algorithm for
		AllocMem() to handle the fact that no paging space has been
		allocated beyond a certain marked point (that is, disallow
		accesses beyond the mark point until AllocMem() gets to there).

		* my favorite, medium difficulty.  One would eventually want
		  to add a ftruncate() command to the filesystem to do this
		  right though.

		File fragmentation is not a problem.. the user can put the
		file on a little-used or unused partition, or make a partition
		specifically to hold the VM-file (but it is his choice!).

	    (C) Reserve a partition to be used for VM.  I do not like this idea
		at all.  In fact, I hate it.  Not only do you need to reserve
		an entire partition, but you can't adjust the size of your VM
		without reformatting the HD!  

		The one advantage is that on system crash the OS can raw-write
		VM to the swap partition without worrying about destroying
		files (cause there are none).  Using a file for VM means that
		on system crash you cannot dump core.  I don't we want to loose
		the functionality of files for paging just so we can dump
		system core.

					-Matt