Subject: Re: pmap_enter() bashed
To: None <email@example.com>
From: Charles M. Hannum <firstname.lastname@example.org>
Date: 03/26/1999 22:00:04
Here's a somewhat long-winded explanation, just to make sure I cover
all the points.
There are two different reasons why we map pages:
1) because we expect to need the page Some Time Later. This can
happen when, e.g., `prefaulting' pages. In this case the
`access_type' is set to 0 and no special action is performed by the
2) because we need the page Right Now, possibly because we got a
fault. In this case, we know that the page is going to be accessed
immediately after the fault handler returns (or, in some cases,
immediately after pmap_enter() returns, as in /dev/mem handling).
We don't want to take another fault just for R/M bit emulation;
this is a complete waste of time. So, the `access_type' serves to
pass the information originally from the fault handler about the
nature of the attempted access back from the VM system to the pmap,
so that the pmap can preset the emulated R/M bits and avoid causing
a second fault.
On machines where the R/M bits are kept in hardware, this doesn't
buy you much. Given the typical pmap implementation structure of
having `cached' copies of the R/M bits in the head of each p->v
list, it could be used to preset those cached bits, giving a slight
optimization on the next call to pmap_is_modified() or
There is a secondary use for this on machines that do R/M bit
emulation, as mentioned in my previous mail. If pagemove() is
implemented such that it flips pages around behind the VM system's
back (as it does on the ARM), then the pages must be accessible all
the time; the R/M bit emulation information (i.e. the attributes in
the pmsegs) is not consistent in this case and must not be used.
Mapping these pages with an access_type of READ|WRITE insures that
R/M emulation never happens on those machines (assuming the pmap
implementation has been changed appropriately), and thus avoids
needing to switch to using pmap_remove() and pmap_enter() inside
pagemove() (as some other ports have done, and which is slower).
I believe both SPARC platforms have hardware R/M bits, so there isn't
much need for any change there.