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: Fri, 8 Jan 1993 04:52:59 GMT

In article <jprad.726451953@faatcrl> jprad@faatcrl.faa.gov (Jack Radigan) writes:
>davidme@qdpii.comp.qdpi.oz.au (David Meiklejohn) writes:
>
>>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.

Message passing is what makes memory (or process) protection on the Amiga a
difficult proposition.  It's been thrashed out here lots of times (and how to
implement private memory spaces under AmigaOS is still an interesting topic,
but I'll try to stay ON topic - not that VM seems to have anything to do with
Computer Chronicles!  :-).

Anyway, as I've said before, I think you really have to look at AmigaOS and the
running applications as being just one "process", in the classic sense.  You
could implement VM, but not offer any sort of intertask protection.  So there'd
be no difference between referencing a message and working on private data.

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

That's no *extra* overhead, assuming that you're already using the MMU for
task protection.  Since we're not, at the moment, implementing VM must cost
us something.  On the other hand, once we had VM support in the OS, MP would
start to look more achievable.  It works both ways.

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

It might, yes.  Then again, we're not talking about C64s here.  Code size
shouldn't be that big compared to RAM, so overlays won't help that much.
Unless the program is huge, in which case it may be hard for the programmer to
make the right decisions.  The bigger the code, the less likely it is that
anyone really understands what's going on in it...  The other possibility is
that you are doing a lot of multitasking, in which case the OS will have the
best idea of what code is being used the least.

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

No, but you really answered this above.  It's there for when your load spills
over what you'd be able to handle without it.  Under an average load, the
system shouldn't swap.  And, now that I've said that several times, I'm not
going to say it again.  I'll try to stay out of this discussion until it
stops going in circles.


>  -jack-


-- 
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
Newsgroups: comp.sys.amiga.advocacy