From: jprad@faatcrl.faa.gov (Jack Radigan)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: CBM mention on 12/11/92 Computer Chronicles
Date: 8 Jan 93 00:35:09 GMT
Organization: FAA Technical Center, Pomona, NJ
NNTP-Posting-Host: faatcrl.faa.gov

davidme@qdpii.comp.qdpi.oz.au (David Meiklejohn) writes:

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

  Those were two terribly worded questions, sorry about that.  I was trying,
ineffectively, to point to the switcher model in the MAC versus true VM and
ended up looking totally ignorant of how VM works.

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

  Depends on if you're going to change the way other things are done WRT 
messages and such, wouldn't a referenced system like AmigaDOS require process 
segment swapping?  Of course, memory allocated by the process could be paged
though.

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

  I'm not that knowledgable at that low a level, I'll take your word for it,
but it doesn't jive with my sense of "getting something for nothing"... ;-)

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

  Again, poorly worded.  I was trying to focus on a single-tasking environment
where an overlayed program might provide for better performance without the
added overhead of VM (which you suggest is minimal).

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

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

  The systems I'm in contact with are always tuned so that physical memory
can handle an average load without having VM come into play except for cases
like end-of-month accounting and other database maintenance that might spill
over from 2nd and 3rd shift to the day shift when the users are on the system.

  In those cases VM takes up the slack so that the extra processing can still
be accomplished while allowing the users to work.

  But again, all this is in a multiuser environment, I can't now, nor can I
ever see the need for VM in a single user system.  It might be nice to have,
just in case, but it's no panacea.

  -jack-