Path: utzoo!attcan!uunet!lll-winken!ncis.tis.llnl.gov!helios.ee.lbl.gov!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: <8905162209.AA20997@postgres.Berkeley.EDU>
Date: 16 May 89 22:09:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 60


I write:
:- That a new MEMF_VIRTUAL flag be added. The idea is to maintain compatibility

Valentin Pepelea 451061@acadvm1.UOttawa.CA writes:
: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

	You are clearly missing the point.  Certainly I would much rather
have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break 
too many programs... more than too many, a *huge* number of programs.

I write:
:- 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.


Valentin Pepelea 451061@acadvm1.UOttawa.CA writes:
: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:

	Here you are wrong for many reasons.  (1) Using a fixed partition
restricts the USER's ability to configure the system the way he likes... i.e.
he must reformat his hard drive to change the swap partition size.  (2) It
requires an entirely new module to be written to handle the independant
trackdisk.device interface.  (3) It is not implementable in the near future. 
(4) it does not ease the way for eventual file mapping which is where UNIX is
going these days.  (5) Your basic assumption that managing a custom swap
partition would be faster than using a file is incorrect.

	The only point I need to embellish upon as the last one.  Frankly,
I think that with appropriate modifications to the fast file system, using
the FFS would be nearly as efficient as a custom partition.  NOT ONLY THAT
BUT USING IT WITHOUT MODIFICATION WOULD BE VIABLE, and not much slower than
a custom partition.  Certainly not more than 10% slower and I'd wager the
difference would be even less than that.

: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

	You are assuming here that an FFS file is 3 TIMES SLOWER!  Bullshit.

:Valentin

					-Matt