Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!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: <8905181656.AA08138@postgres.Berkeley.EDU>
Date: 18 May 89 16:56:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 20

:>in article <8905162209.AA20997@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) says:
:>
:>> NOT ONLY THAT BUT USING [FFS] WITHOUT MODIFICATION WOULD BE VIABLE, and not
:>> much slower than a custom partition.  Certainly not more than 10% slowerand
:>> I'd wager the difference would be even less than that.
:>
:Dave Haynie  "The 32 Bit Guy"  Writes:
:>Not only that, but if you're willing to live with a SWAP: file that doesn't 
:>move during the life of an active VM system, you can have you're cake and 
:>eat it too.
:>Given an file in FFS, it's rather easy to chase down the device driver level
:>location of evey block in that file.  A translation table of sorts would allow

	Yes, exactly!  VM can easily be implemented using files and the
theoretical efficiency limit approaches that of a custom partition.  I say
get it working first (even if only 80-90% efficient) and worry about 
remembering all file blocks later.   Remember, currently side sectors are
cached which is where I got my 80-90% efficiency number from.

				-Matt