From: davidme@qdpii.comp.qdpi.oz.au (David Meiklejohn)
Subject: Re: CBM mention on 12/11/92 Computer Chronicles
Organization: Qld Dept Primary Industries
Date: Wed, 6 Jan 1993 11:15:29 GMT

In article <jprad.726296079@faatcrl> jprad@faatcrl.faa.gov (Jack Radigan) writes:
>jerry@msi.com (Jerry Shekhel) writes:
>
>>Yes, but VM can help you make the best use of your physical RAM (by swapping
>>out unused code).
>
>  But how does the system "know" which code to swap out?  Is it the entire
>code segment for a program, or just sections of it?  

Hmmm...  I don't really want to write a tutorial on VM impementation here,
but it's obvious from this discussion that some people here lack a clue or
two.  So, here goes - I'll be brief, though.

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.

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.

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

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

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.

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

>  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