Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!cs.utexas.edu!bryan
From: bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory / doable 1.4 request
Message-ID: <347@mohawk.cs.utexas.edu>
Date: 17 May 89 21:50:05 GMT
References: <8905132040.AA27524@postgres.Berkeley.EDU> <DEVEN.89May17023146@daniel.rpi.edu>
Reply-To: bryan@cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 41
Spam-Content: Negligible

In article <DEVEN.89May17023146@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes:
=-
=-Matt, Matt...  Here you seem to suffer from a lack of foresight.  This
=-is NOT an ideal way to implement it.  I'd say the proper way to
=-implement it is to modify AllocMem and design the pager such that all
=-available memory (i.e. unallocated real RAM) may be used for VM.  If
=-you have 2MB of RAM and a process is using 20MB of VM, and another
=-process is using .5MB (including system overhead, we'll say) of real
=-RAM, then the remaining 1.5MB of RAM should be used for the VM.  Then,
=-if the other process were to allocate another 1MB of real RAM, then
=-AllocMem should call the pager to flush 1MB of the VM pages allocated,
=-and reallocate them as real RAM for the other process.  Similarly,
=-upon a FreeMem, the system should return as much of the freed memory
=-as is usable [that are of full VM pagesize, after freelist merge] to
=-the pager to lessen paging required.
=-
=-In this way, if there is real RAM free, any program which needs it can
=-allocate it, but if it is unused, then let it be used for VM as
=-necessary, reclaiming the VM-paging real RAM pages on demand.  You get
=-dynamic usage of the available memory, and optimum efficiency at all
=-times, without worrying how much memory you need to set aside for
=-either real RAM or VM paging space.  What's leftover is simply used
=-for paging, automatically.
=-
	Yeah, I thought of posting the same response to Matt's article, but
there is a problem.  Neglecting chip RAM, the reason a task needs physical
memory is to guarantee fixed execution time for instructions, and for calls to
AllocMem.  Now, you can lock the page frames occupied by the code at load time,
but if you allow AllocMem to kick out a VM page, and the page is dirty, then
you have to wait for the pager to run and write the page out to disk.  I can
think of a couple of solutions to this, but none are much better than
statically partitioning memory.  Of course, if you don't run any real-time
programs, then the idea remains elegant, and I'm glad I had it first. :-)

 ______________________________________________________________________________ 
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|_____|_bryan@cs.utexas.edu___|
___|_____|_____|_____|_____|_____|_____|{vertebrae...}!cs.utexas.edu!bryan_|___
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|