Article View: comp.sys.amiga.tech
Article #12682Re: Virtual Memory / doable 1.4 request
From: Valentin Pepelea
Date: Tue, 16 May 1989 04:03
Date: Tue, 16 May 1989 04:03
59 lines
3793 bytes
3793 bytes
Matt Dillon <dillon@postgres.berkeley.edu> in message
<8905132040.AA27524@postgres.Berkeley.EDU> as well as in other messages
introduces some ideas involving virtual memory. Let s analyse them one by one.
- That a new MEMF_VIRTUAL flag be added. The idea is to maintain compatibility
- for older programs which mishandle critical sections, while new programs
- may specifically request virtual memory pages.
This is a prime example of what should not be done. If we are to implement
virtual memory, let s do it right the first time. Do we want to create
compatibility cludges and end up with version 7.0 of AmigaDOS which will be
stuck in old technology and incapable of running the majority of applications?
Look at what Apple is stuck with. Let s rough up a few feathers, and illuminate
the right path.
I propose that a new MEMF_PHYSICAL flag be added. memory requested with this
flag will be guaranteed never to be swapped in and out, and thus would be the
ideal location for device drivers and other real-time programs. If a user
wishes to run a program that does not, all he has to do is not install the
virtual memory handler. This is a real neat feature of the upcoming virtual
memory and memory protection handlers; they can be installed long after the
Amiga has been booted and running.
- That as a SWAP: device, a file be used. The potential advantages of this are
- numerous, and include to ability to increase dynamically the size of the
- virtual memory, and the ability to locate the file anywhere.
But this is another prime example of what should not be done. It is much
preferable to use a reserved fixed partition of a hard drive for speed. Files
are great when you wish to store and access data sequentially. But when fixed
size blocks (pages) have to be accessed randomly, going through the file system
will slow down the access time by a factor of ten, optimistically. Since the
memory requirement versus access time speed is exponentially proportional
(inversly), we will need three times more physical ram to map into. Choose:
SWAP: is a DOS file Physical: 6 Mbytes Virtual: 40 Mbytes
SWAP: is a partiiton Physical: 2 Mbytes Virtual: 40 Mbytes
So you see, the hard disk s access time plays a primordial role in our
selection of how much physical ram we need to map into, and how large our page
size is going to be. It would be best to have a Quantum 19ms drive devoted
solely to virtual memory thus not even allowing other programs to play with
the postion of the drive s head.
Note that the size of the virtual addressing space (40 Meg) is not at all a
factor in the page size and physical ram size. But rather the number of
programs you are running, and their atomicity is. For example Smalltalk and
Forth programs would prefer 512 byte pages, while C programs would prefer
2K pages. Um, make that 4K. So allot as large a virtual addressing space as
your hard drive allows you too.
Valentin
_________________________________________________________________________
"An operating system without Name: Valentin Pepelea
virtual memory is an operating Phonet: (613) 233-1821
system without virtue." Bitnet: 451061@Uottawa.bitnet
Usenet: Use cunyvm.cuny.edu gate
- Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
Technical Details
Message-ID:
<8905160628.AA06371@jade.berkeley.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!UOTTAWA.BITNET!451061Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!UOTTAWA.BITNET!451061 From: 451061@UOTTAWA.BITNET (Valentin Pepelea) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / doable 1.4 request Message-ID: <8905160628.AA06371@jade.berkeley.edu> Date: 16 May 89 04:03:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59