Path: 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 Matt Dillon 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