🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #12705

Re: Virtual Memory / doable 1.4 request

#12705
From: Valentin Pepelea
Date: Wed, 17 May 1989 03:14
91 lines
5173 bytes
Matt Dillon <dillon@postgres.berkeley.edu> writes in
Message-ID: <8905162209.AA20997@postgres.Berkeley.EDU>

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

Would you not rather break many programs today, when there are so few potential
A2500 owners and users of virtual memory, than three years from now when every
body will be having MMUs in their Amigas? (wishful thinking) I would rather
burn naughty devellopers now, when there is 1 user of VM, than three years from
now, when there will be 2 million.

> (1) Using a fixed partition restricts the USER's ability to configure the
> system the way he likes...

Agree with you there, although the driver for the SWAP: device does not
necessarely have to be a harddisk.device. Flexibility is maintained, though
not as elastic as if a file were used.

> (2) It requires an entirely new module to be written to handle the
> independent trackdisk.device interface.

Definitely not. The SWAP: device should be a mere hard disk partition
controlled by access through the harddisk.device. Ultimately a custom driver
should be used only if the harddisk.device driver proves to be to slow.
Unlikely

> (3) It is not implementable in the near future.

Preposterous! Virtual memory can be written within a week by somebody who knows
what he is doing. A handler will be available by the end of the summer, I will
bet my iron ring on that.

> (4) it does not ease the way for eventual file mapping which is where UNIX is
> going these days.

Hmmm, you seem to have Unix etched in your head. I bet you are one of those
guys who has written a CSH-like shell for the Amiga. Unix is a prime example of
the direction the Amiga should not be going into. Unix is slow, Unix is big,
Unix is cumbersome. The Amiga on the other hand is a real-time system, small,
compact, fast. Useful. The Amiga provides a common addressing space for all
concurrent tasks, a most useful feature than can only be provided in single-
user systems. Unix intents to map the individual addressing spaces of each
process to a file, which is ideal for multi-user systems where programs have
to have their own addressing space. That is clearly not what we are dealing
with on the Amiga. We have a single addressing space, and we know in advance
the range to which we want this addressing space to be limited to.

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

...after my example...

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

Quite clearly, you do not understand. FFS is fast because after an initial
sector is found, the following ones are loaded sequentially off the same track.
Thus for large files, the tranfer rate is impressive. But for small scattered
files, FFS is not better than the old file system. For paging, we have to
transfer individual 512 bytes pages which are never needed in a sequential
order. Thus the overhead that the filing system introduces to find the
approriate sector on disk increases seek time by an order of magnitude. The
example I gave said the filing system would be 10 times slower, not 3, thus
requiring three times more physical memory. sqrt(10)=3


For swapping page 316, it is much simpler to transfer directly sector 316
through the trackdisk.device, than having to determine the location of the
sector through a filing system.

The only way a filing system could be used in this case would be by an indexed
access method, or database access method filing system. A good example of such
a marvel is INFOS II on Data General computers. I hear the Software Distillery
is working on just such a beast. No wonder, since John Toebes used to hack on
DG systems.

Valentin
_________________________________________________________________________
"An  operating  system  without         Name:   Valentin Pepelea
 virtual memory is an operating         Phonet:
 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: <8905170500.AA25917@jade.berkeley.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!UOTTAWA.BITNET!451061

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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: <8905170500.AA25917@jade.berkeley.edu>
Date: 17 May 89 03:14:44 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 91