Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!noao!asuvax!behemoth!mph
From: mph@behemoth.phx.mcd.mot.com (Mark Huth)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory
Message-ID: <10949@behemoth.phx.mcd.mot.com>
Date: 23 May 89 22:10:49 GMT
References: <8905222150.AA05890@jade.berkeley.edu>
Reply-To: mph@behemoth.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 25

In article <8905222150.AA05890@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:
>
>I though about this once again, and once again I came to the conclusion that
>it does not matter wether you can trap the Forbid()/Disable calls, since the
>problem is not that multitasking is disabled, but rather that we do not know
>*why* it is disabled. Thus we do not know what reparative action to take, and
>thus wether we are allowed to perform page swapping or not.

Well, I'm not Dave, but I'll jump in here.  Forbid in not too bad - just eats
processor doing nothing while the page swap occurs.  That is, we do not care why
the task forbids, we simply comply by not scheduling another context.  If a
page fault occurs, swap a page.  If it was the wrong page, then you'll get
another page fault, so you swap that one in.  Assuming you use something other
than most-recently-used for the selection of targets for swapping, you'll
eventually end up with the proper page set in memory and complete the critical
region.

Disable is another story, as you may well need interrupts for the page
swapper.  I would say that if you're in the area where interrupts really
need to be disabled, then you're mucking with the hardware, and the code
is probably not a good candidate for VM.  I mean, at least some of the
code will access physical registers. Normally, this code is inside the OS
kernel and not run under VM.

Mark Huth