Path: utzoo!attcan!uunet!lll-winken!xanth!ames!pasteur!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: <8905181705.AA08260@postgres.Berkeley.EDU>
Date: 18 May 89 17:05:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 27

:>        (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.
:
: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

	Hey Hey!  A guy can make mistakes!  You are right of course... all
(or most) of real memory should be under VM but have the ability to 'lock'
pages into memory as has been mentioned.

	The only problem is that AllocMem() requests are normally quite
small... much smaller than a page, so management becomes more difficult if
all of real memory is in VM.  Still, it isn't much of a problem.

	On this MEMF_PHYSICAL vs MEMF_VIRTUAL bit.  Sure MEMF_PHYSICAL is
a nice way to say 'I want memory and it should be locked', and I'd much rather
have that than MEMF_VIRTUAL (which says 'I want this memory to be pagable'),
but really the only way to guarentee upward compatibility is to make 
physical the default and MEMF_VIRTUAL the exception.  Thus have a MEMF_VIRTUAL
AllocMem() flag and not a MEMF_PHYSICAL flag.

					-Matt