From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: CBM mention on 12/11/92 Computer Chronicles
Date: 6 Jan 1993 21:39:09 GMT
Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.2.33

In article <1993Jan6.111529.12169@qdpii.comp.qdpi.oz.au> davidme@qdpii.comp.qdpi.oz.au (David Meiklejohn) writes:
>two.  So, here goes - I'll be brief, though.

Sure.  :)

>VM on the Amiga would probably be paged.  There are alternatives - for example,
>the 286 implements VM by swapping out segments, which can vary in size.
>However, paged memory management is what the MMUs in the '030 and '040 are
>designed for.

Well, it seems to me that the 040's mmu is a bit "skeletal" in
representation.  The 040's mmu is so barren that you practically need
to keep a full memory map of the entire system, and it's not as
flexible as the 030's was.  I feel sorry for Mike Sinz and Enforcer
v37.xx, because I can imagine the contortions he must have had to
endure to trick the MMU like that...

>A piece of code running on a CPU sees an address space it can use, with no
>complications.  Address 1000 is address 1000, as far as it's concerned.  This
>is called virtual memory space, and, in a protected memory environment, each
>process sees its own (virtual) space.  Of course, this doesn't have to apply
>on an Amiga, where it's easier to think of tasks as threads of execution
>sharing a single process space.  That doesn't stop us having VM - I only
>mention that because most descriptions of VM in OS theory texts discuss it in
>terms of multiple processes.

(I feel like Dan Dierdorf)  Correct.  That's why a lot of people say
that with MP, you almost get VM for free.  If you're going to use MP,
the best way to do it would be to give each program its own virtual
space, and that facilitates easy VM.

>So, this virtual memory that the process sees is divided by the MMU into a
>series of pages, typically 4k or so in size.  The page size will be set by
>the OS (assuming the MMU is flexible enough), but all pages are the same size.

That's a big assumption for the 040.  B[  Those pages determine, as
one can guess, the size of the section of ram that is moved around is
determined by the page size.  This also, naturally, determines the
amount of performance drop each page fault incurrs upon the system.

Curiosity:  Does a page fault clear caches?  That's something else to
remember, I'm pretty sure VM does some nasty things to cache coherency.

>Now, here's the clever bit.  For each page, there's an entry in a table (held
>in physical RAM) which records where that virtual page resides.  If there's
>enough physical RAM, there'll be a one-to-one correspondence between virtual
>and physical pages.  However, virtual pages can be stored anywhere in physical
>RAM - they don't need to be sequential, or contiguous.  This has a great
>advantage - you avoid memory fragmentation, since as far as the process is
>concerned, its memory is unfragmented, even if it's all jumbled up in
>physical RAM.  The MMU handles the necessary address translation, converting
>virtual addresses to real addresses on the fly.  That means referencing the
>translation table for each memory access, so to avoid the overhead associated
>with that, the '030 has an address translation cache (don't know about the
>'040, sorry).  The cache won't always be hit, so this paging business will
>impose some small overhead.

Of course, this, on the Amiga, would only cover Fast ram.  I do not
believe it is possible to achieve VM in chip ram under the current
architecture of the chip ram bus, due to the "owner" being someone
other than the main CPU.  (That was a gutsy, gutsy play...)

Do remember that the entire memory map for the MMU actually exists,
and takes up, depending on the system, a fair amount of ram itself.
Isn't it 2 megs or something for the 040's memory map, without trickery?

If I'm lucky, Mike Sinz will step in and tell us a bit about the 030
and 040's mmu's.  This could turn into a kind of MMU theory course.
:)

So, that means in order to have enough ram to avoid swapping with the
MMU, one must have enough ram for the application AND enough ram for
the memory map.  On the 040, if the 2Mb figure I remember is correct,
parts of that memory map _CAN_ be stored in VM.  There may also be a
way of constructing things "on the fly" so as to avoid having a memory
map of enormous size.  I do believe that perahps Enforcer does
something like this.  :)

>Now, what happens if your virtual address space is bigger than physical ram?
>Well, when a virtual page is accessed, the MMU checks the translation table
>to see if it already has a physical page allocated to it.  If so, no problem.
>It just translates the address and we're done.  If not, a new physical page
>needs to be found and allocated.  Also not a problem, unless there are none
>left.  In that case, one of the other pages, currently sitting in physical
>RAM, needs to be gotten rid of.  Now, there are various strategies for choosing
>the page to get rid of, but the one least recently accessed is probably a
>good choice.  This page is written to disk, and this fact is recorded in the

It should be said that there are lots and lots and lots of algorithms
for choosing which page to remove, and every system seems to use its
own.  :)

>translation table.  The physical page is then free for use by the virtual page
>currently being accessed.  When the page that was written to disk is needed
>again, another physical page needs to be written out to disk, and the page
>we're after read in.  This is called "swapping".  Too much swapping is called
>"thrashing".

Too much thrasing is called "Time to go out and buy more ram".  :)  It
is also important to understand that programs like the Enforcer take
over the function of the MMU, and would not be usable with a program
such as GigaMem which allows VM.  Programs like MungWall would be
devastating under VM, and starting MungWall could very well be the
last thing you ever do, under a VM system where all programs are in
the same virtual map.  You'd, nearly instantaneously, be paging
everything out as MungWall went to the edge of your virtual space
filling everything with $DEADBEEF.  It would actually be kind of
funny, I suppose.  :)

Anyone wanna try it and time it?  It might be a funny little note for
an .advocacy FAQ.  ;)

>All this swapping business is too complicated for the humble MMU to deal
>with, so when a virtual page isn't sitting in physical RAM, it generates what
>they call a page fault, and the OS then deals with it.  So, having VM doesn't
>impose any extra overhead as long as everything fits in RAM.

Or, in GigaMem's case, GigaMem.  VM _COULD_ impose extra overhead
though, and this is something to remember.  Though the 030 and 040
MMU's impose no overhead, the 020 and its external MMU, the 68851,
impose, if I remember correctly, a 1 cycle delay with each MMU access.
(someone tell me if I'm right, please).  This could considerably slow
down the system.  Though the 68851 is rare to see now, it is still a
concern as it is, from what I understand, rather compatible with the
030's mmu (If I remember correctly, the 68851 has a superset of the
030's MMU instruction set), and there are many people out there with
020+851 combinations.

>So endeth the lesson.  Hopefully it answers Jack's question.

Hopefully, I've explained a bit of Amiga specifics.  :)

>>  If the entire program gets swapped out it sounds like a simple-minded task 
>>switcher to me, not a multitasking OS.
>>
>>  If it's sections of a program you're after then an overlay manager sounds
>>like a better bet since the application's author(s) would know best how to
>>construct the overlay map for a minimal ram image during run time.
>
>No, it's not task switching, and it's not overlays.
>
>>  Funny, but all references to VM that I've run into point to data, not code
>>being the occupant, it allows for larger datasets for time-intensive
>>operations, like sorts and the like.  It's certainly faster to sort via VM
>>then dedicate an operator and a few drives for a shift or two of reel
>>swapping...
>>
>>  But for code?  Blech!
>
>The really important point is that the process I described above makes no
>distinction between code and data.  All the MMU sees is addresses being
>generated.  In practice, you'd expect code to be accessed more often than
>data, so it wouldn't normally be a candidate for swapping out.  But, some of
>the code may be rarely used - perhaps there's one module of an application
>that's working with a heap of data that's filling RAM.  Then, the other parts
>of the program that aren't in use could be swapped out.  What you need to
>realise, though, is that the VM system doesn't need to know any of that.  It
>just sees some RAM that hasn't been accessed in a while.  Whether or not code
>is available for swapping is up to the OS, anyway.  You could have VM for
>data space only, if you wanted.  Certainly, though, Unix has no problems with
>swapping code out.
>
>
>-- 
>David Meiklejohn (davidme@qdpii.comp.qdpi.oz.au)
> - PC's, Unix, and networks by day, Amigas by night...
>Currently residing in Mareeba, Far North Queensland, Australia


--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(: "Our father, who art in Iowa, Hollow be thy head, Thy ideas run    :)
(:  Thy will be done, At Commodore as it is at Apple"  -Dan Barrett   :)
(: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
Newsgroups: comp.sys.amiga.advocacy