pmap - machine-dependent portion of the virtual memory system
#include <sys/param.h>
#include <uvm/uvm_extern.h>
void
pmap_init(void);
void
pmap_virtual_space(vaddr_t *vstartp, vaddr_t *vendp);
vaddr_t
pmap_steal_memory(vsize_t size, vaddr_t *vstartp, vaddr_t *vendp);
pmap_t
pmap_kernel(void);
pmap_t
pmap_create(void);
void
pmap_destroy(pmap_t pmap);
void
pmap_reference(pmap_t pmap);
void
pmap_fork(pmap_t src_map, pmap_t dst_map);
long
pmap_resident_count(pmap_t pmap);
long
pmap_wired_count(pmap_t pmap);
vaddr_t
pmap_growkernel(vaddr_t maxkvaddr);
int
pmap_enter(pmap_t pmap, vaddr_t va, paddr_t pa, vm_prot_t prot,
int flags);
void
pmap_remove(pmap_t pmap, vaddr_t sva, vaddr_t eva);
void
pmap_protect(pmap_t pmap, vaddr_t sva, vaddr_t eva, vm_prot_t prot);
void
pmap_unwire(pmap_t pmap, vaddr_t va);
boolean_t
pmap_extract(pmap_t pmap, vaddr_t va, paddr_t *pap);
void
pmap_kenter_pa(vaddr_t va, paddr_t pa, vm_prot_t prot);
void
pmap_kremove(vaddr_t va, vsize_t size);
void
pmap_copy(pmap_t dst_map, pmap_t src_map, vaddr_t dst_addr, vsize_t len,
vaddr_t src_addr);
void
pmap_collect(pmap_t pmap);
void
pmap_update(pmap_t pmap);
void
pmap_activate(struct proc *p);
void
pmap_deactivate(struct proc *p);
void
pmap_zero_page(paddr_t pa);
void
pmap_copy_page(paddr_t src, paddr_t dst);
void
pmap_page_protect(struct vm_page *pg, vm_prot_t prot);
boolean_t
pmap_clear_modify(struct vm_page *pg);
boolean_t
pmap_clear_reference(struct vm_page *pg);
boolean_t
pmap_is_modified(struct vm_page *pg);
boolean_t
pmap_is_referenced(struct vm_page *pg);
paddr_t
pmap_phys_address(int cookie);
vaddr_t
PMAP_MAP_POOLPAGE(paddr_t pa);
paddr_t
PMAP_UNMAP_POOLPAGE(vaddr_t va);
The pmap module is the machine-dependent portion of the NetBSD virtual
memory system uvm(9). The purpose of the pmap module is to manage physical
address maps, to program the memory management hardware on the system,
and perform any cache operations necessary to ensure correct operation
of the virtual memory system. The pmap module is also responsible
for maintaining certain information required by uvm(9).
In order to cope with hardware architectures that make the invalidation
of virtual address mappings expensive (e.g. TLB invalidations, TLB
shootdown operations for multiple processors), the pmap module is allowed
to delay mapping invalidation or protection operations until such time as
they are actually necessary. The functions that are allowed to delay
such actions are pmap_enter(), pmap_remove(), pmap_protect(),
pmap_kenter_pa(), and pmap_kremove(). Callers of these functions must
use the pmap_update() function to notify the pmap module that the mappings
need to be made correct. Since the pmap module is provided with
information as to which processors are using a given physical map, the
pmap module may use whatever optimizations it has available to reduce the
expense of virtual-to-physical mapping synchronization.
HEADER FILES AND DATA STRUCTURES [Toc] [Back]
Machine-dependent code must provide the header file <machine/pmap.h>.
This file contains the definition of the pmap structure:
struct pmap {
/* Contents defined by pmap implementation. */
};
typedef struct pmap *pmap_t;
This header file may also define other data structures that the pmap
implementation uses.
Note that all prototypes for pmap interface functions are provided by the
header file <uvm/uvm_pmap.h>. It is possible to override this behavior
by defining the C pre-processor macro ``PMAP_EXCLUDE_DECLS''. This may
be used to add a layer of indirection to pmap API calls, for handling
different MMU types in a single pmap module, for example. If the
``PMAP_EXCLUDE_DECLS'' macro is defined, <machine/pmap.h> must provide
function prototypes in a block like so:
#ifdef _KERNEL /* not exposed to user namespace */
__BEGIN_DECLS /* make safe for C++ */
/* Prototypes go here. */
__END_DECLS
#endif /* _KERNEL */
The header file <uvm/uvm_pmap.h> defines a structure for tracking pmap
statistics (see below). This structure is defined as:
struct pmap_statistics {
long resident_count; /* number of mapped pages */
long wired_count; /* number of wired pages */
};
WIRED MAPPINGS [Toc] [Back]
The pmap module is based on the premise that all information contained in
the physical maps it manages is redundant. That is, physical map information
may be ``forgotten'' by the pmap module in the event that it is
necessary to do so; it can be rebuilt by uvm(9) by taking a page fault.
There is one exception to this rule: so-called ``wired'' mappings may not
be forgotten. Wired mappings are those for which either no high-level
information exists with which to rebuild the mapping, or mappings which
are needed by critical sections of code where taking a page fault is
unacceptable. Information about which mappings are wired is provided to
the pmap module when a mapping is established.
MODIFIED/REFERENCED INFORMATION
The pmap module is required to keep track of whether or not a page managed
by the virtual memory system has been referenced or modified. This
information is used by uvm(9) to determine what happens to the page when
scanned by the pagedaemon.
Many CPUs provide hardware support for tracking modified/referenced
information. However, many CPUs, particularly modern RISC CPUs, do not.
On CPUs which lack hardware support for modified/referenced tracking, the
pmap module must emulate it in software. There are several strategies
for doing this, and the best strategy depends on the CPU.
The ``referenced'' attribute is used by the pagedaemon to determine if a
page is ``active''. Active pages are not candidates for re-use in the
page replacement algorithm. Accurate referenced information is not
required for correct operation; if supplying referenced information for a
page is not feasible, then the pmap implementation should always consider
the ``referenced'' attribute to be FALSE.
The ``modified'' attribute is used by the pagedaemon to determine if a
page needs to be cleaned (written to backing store; swap space, a regular
file, etc.). Accurate modified information must be provided by the pmap
module for correct operation of the virtual memory system.
Note that modified/referenced information is only tracked for pages managed
by the virtual memory system (i.e. pages for which a vm_page structure
exists). In addition, only ``managed'' mappings of those pages have
modified/referenced tracking. Mappings entered with the pmap_enter()
function are ``managed'' mappings. It is possible for ``unmanaged'' mappings
of a page to be created, using the pmap_kenter_pa() function. The
use of ``unmanaged'' mappings should be limited to code which may execute
in interrupt context (for example, the kernel memory allocator), or to
enter mappings for physical addresses which are not managed by the virtual
memory system. ``Unmanaged'' mappings may only be entered into the
kernel's virtual address space. This constraint is placed on the callers
of the pmap_kenter_pa() and pmap_kremove() functions so that the pmap
implementation need not block interrupts when manipulating data structures
or holding locks.
Also note that the modified/referenced information must be tracked on a
per-page basis; they are not attributes of a mapping, but attributes of a
page. Therefore, even after all mappings for a given page have been
removed, the modified/referenced information for that page must be preserved.
The only time the modified/referenced attributes may be cleared
is when the virtual memory system explicitly calls the
pmap_clear_modify() and pmap_clear_reference() functions. These functions
must also change any internal state necessary to detect the page
being modified or referenced again after the modified or referenced state
is cleared. (Prior to NetBSD 1.6, pmap implementations could get away
without this because UVM (and Mach VM before that) always called
pmap_page_protect() before clearing the modified or referenced state, but
UVM has been changed to not do this anymore, so all pmap implementations
must now handle this.)
STATISTICS [Toc] [Back]
The pmap is required to keep statistics as to the number of ``resident''
pages and the number of ``wired'' pages.
A ``resident'' page is one for which a mapping exists. This statistic is
used to compute the resident size of a process and enforce resource limits.
Only pages (whether managed by the virtual memory system or not)
which are mapped into a physical map should be counted in the resident
count.
A ``wired'' page is one for which a wired mapping exists. This statistic
is used to enforce resource limits.
Note that it is recommended (though not required) that the pmap implementation
utilize the pmap_statistics structure in the tracking of pmap
statistics by placing it inside the pmap structure and adjusting the
counts when mappings are established, changed, or removed. This avoids
potentially expensive data structure traversals when the statistics are
queried.
REQUIRED FUNCTIONS [Toc] [Back]
This section describes functions that a pmap module must provide to the
virtual memory system.
void pmap_init(void)
This function initializes the pmap module. It is called by
uvm_init() to initialize any data structures that the module
needs to manage physical maps.
pmap_t pmap_kernel(void)
Return a pointer to the pmap structure that maps the kernel
virtual address space.
Note that this function may be provided as a C pre-processor
macro.
void pmap_virtual_space(vaddr_t *vstartp, vaddr_t *vendp)
The pmap_virtual_space() function is called to determine
the initial kernel virtual address space beginning and end.
These values are used to create the kernel's virtual memory
map. The function must set *vstartp to the first kernel
virtual address that will be managed by uvm(9), and must
set *vendp to the last kernel virtual address that will be
managed by uvm(9).
If the pmap_growkernel() feature is used by a pmap implementation,
then *vendp should be set to the maximum kernel
virtual address allowed by the implementation. If
pmap_growkernel() is not used, then *vendp must be set to
the maximum kernel virtual address that can be mapped with
the resources currently allocated to map the kernel virtual
address space.
pmap_t pmap_create(void)
Create a physical map and return it to the caller. The
reference count on the new map is 1.
void pmap_destroy(pmap_t pmap)
Drop the reference count on the specified physical map. If
the reference count drops to 0, all resources associated
with the physical map are released and the physical map
destroyed. In the case of a drop-to-0, no mappings will
exist in the map. The pmap implementation may assert this.
void pmap_reference(pmap_t pmap)
Increment the reference count on the specified physical
map.
long pmap_resident_count(pmap_t pmap)
Query the ``resident pages'' statistic for pmap.
Note that this function may be provided as a C pre-processor
macro.
long pmap_wired_count(pmap_t pmap)
Query the ``wired pages"'' statistic for pmap.
Note that this function may be provided as a C pre-processor
macro.
int pmap_enter(pmap_t pmap, vaddr_t va, paddr_t pa, vm_prot_t prot,
int flags)
Create a mapping in physical map pmap for the physical
address pa at the virtual address va with protection specified
by bits in prot:
VM_PROT_READ The mapping must allow reading.
VM_PROT_WRITE The mapping must allow writing.
VM_PROT_EXECUTE The page mapped contains instructions
that will be executed by the
processor.
The flags argument contains protection bits (the same bits
as used in the prot argument) indicating the type of access
that caused the mapping to be created. This information
may be used to seed modified/referenced information for the
page being mapped, possibly avoiding redundant faults on
platforms that track modified/referenced information in
software. Other information provided by flags:
PMAP_WIRED The mapping being created is a wired
mapping.
PMAP_CANFAIL The call to pmap_enter() is allowed
to fail. If this flag is not set,
and the pmap_enter() call is unable
to create the mapping, perhaps due to
insufficient resources, the pmap module
must panic.
The access type provided in the flags argument will never
exceed the protection specified by prot. The pmap implementation
may assert this. Note that on systems that do
not provide hardware support for tracking modified/referenced
information, modified/referenced information for the
page must be seeded with the access type provided in flags
if the PMAP_WIRED flag is set. This is to prevent a fault
for the purpose of tracking modified/referenced information
from occurring while the system is in a critical section
where a fault would be unacceptable.
Note that pmap_enter() is sometimes called to enter a mapping
at a virtual address for which a mapping already
exists. In this situation, the implementation must take
whatever action is necessary to invalidate the previous
mapping before entering the new one.
Also note that pmap_enter() is sometimes called to change
the protection for a pre-existing mapping, or to change the
``wired'' attribute for a pre-existing mapping.
The pmap_enter() function returns 0 on success or an error
code indicating the mode of failure.
void pmap_remove(pmap_t pmap, vaddr_t sva, vaddr_t eva)
Remove mappings from the virtual address range sva to eva
from the specified physical map.
void pmap_protect(pmap_t pmap, vaddr_t sva, vaddr_t eva, vm_prot_t
prot)
Set the protection of the mappings in the virtual address
range sva to eva in the specified physical map.
void pmap_unwire(pmap_t pmap, vaddr_t va)
Clear the ``wired'' attribute on the mapping for virtual
address va.
boolean_t pmap_extract(pmap_t pmap, vaddr_t va, paddr_t *pap)
This function extracts a mapping from the specified physical
map. It serves two purposes: to determine if a mapping
exists for the specified virtual address, and to determine
what physical address is mapped at the specified virtual
address.
The pmap_extract() function returns FALSE if a mapping for
va does not exist. Otherwise, it returns TRUE and places
the physical address mapped at va into *pap if the pap
argument is non-NULL.
void pmap_kenter_pa(vaddr_t va, paddr_t pa, vm_prot_t prot)
Enter an ``unmanaged'' mapping for physical address pa at
virtual address va with protection prot into the kernel
physical map. Mappings of this type are always ``wired'',
and are unaffected by routines that alter the protection of
pages (such as pmap_page_protect()). Such mappings are
also not included in the gathering of modified/referenced
information about a page. Mappings entered with
pmap_kenter_pa() by machine-independent code must not have
execute permission, as the data structures required to
track execute permission of a page may not be available to
pmap_kenter_pa(). Machine-independent code is not allowed
to enter a mapping with pmap_kenter_pa() at a virtual
address for which a valid mapping already exists. Mappings
created with pmap_kenter_pa() may be removed only with a
call to pmap_kremove().
Note that pmap_kenter_pa() must be safe for use in interrupt
context. splvm() blocks interrupts that might cause
pmap_kenter_pa() to be called.
void pmap_kremove(vaddr_t va, vsize_t size)
Remove all mappings starting at virtual address va for size
bytes from the kernel physical map. All mappings that are
removed must be the ``unmanaged'' type created with
pmap_kenter_pa(). The implementation may assert this.
void pmap_copy(pmap_t dst_map, pmap_t src_map, vaddr_t dst_addr,
vsize_t len, vaddr_t src_addr)
This function copies the mappings starting at src_addr in
src_map for len bytes into dst_map starting at dst_addr.
Note that while this function is required to be provided by
a pmap implementation, it is not actually required to do
anything. pmap_copy() is merely advisory (it is used in
the fork(2) path to ``pre-fault'' the child's address
space).
void pmap_collect(pmap_t pmap)
This function is called just before a process is swapped
out to allow the pmap module to release resources used to
map the process's address space. The implementation may
choose to remove physical mappings in order to free e.g.
page tables back to the system. Note, however, that wired
mappings must not be removed when pmap_collect() is called.
Note that while this function is required to be provided by
a pmap implementation, it is not actually required to do
anything. pmap_collect() is merely advisory. It is recommended,
however, that pmap_collect() be fully implemented
by a pmap implementation.
void pmap_update(pmap_t pmap)
This function is used to inform the pmap module that all
physical mappings, for the specified pmap, must now be correct.
That is, all delayed virtual-to-physical mappings
updates (such as TLB invalidation or address space identifier
updates) must be completed. This routine must be used
after calls to pmap_enter(), pmap_remove(), pmap_protect(),
pmap_kenter_pa(), and pmap_kremove() in order to ensure
correct operation of the virtual memory system.
If a pmap implementation does not delay virtual-to-physical
mapping updates, pmap_update() has no operation. In this
case, the call may be deleted using a C pre-processor macro
in <machine/pmap.h>.
void pmap_activate(struct proc *p)
Activate the physical map used by process p. This is
called by the virtual memory system when the the virtual
memory context for a process is changed, and is also often
used by machine-dependent context switch code to program
the memory management hardware with the process's page
table base, etc. Note that pmap_activate() may not always
be called when p is the current process. pmap_activate()
must be able to handle this scenario.
void pmap_deactivate(struct proc *p)
Deactivate the physical map used by process p. It is generally
used in conjunction with pmap_activate(). Like
pmap_activate(), pmap_deactivate() may not always be called
when p is the current process.
void pmap_zero_page(paddr_t pa)
Zero the PAGE_SIZE sized region starting at physical
address pa. The pmap implementation must take whatever
steps are necessary to map the page to a kernel-accessible
address and zero the page. It is suggested that implementations
use an optimized zeroing algorithm, as the performance
of this function directly impacts page fault performance.
The implementation may assume that the region is
PAGE_SIZE aligned and exactly PAGE_SIZE bytes in length.
Note that the cache configuration of the platform should
also be considered in the implementation of
pmap_zero_page(). For example, on systems with a physically-addressed
cache, the cache load caused by zeroing the
page will not be wasted, as the zeroing is usually done ondemand.
However, on systems with a virtually-addressed
cached, the cache load caused by zeroing the page will be
wasted, as the page will be mapped at a virtual address
which is different from that used to zero the page. In the
virtually-addressed cache case, care should also be taken
to avoid cache alias problems.
void pmap_copy_page(paddr_t src, paddr_t dst)
Copy the PAGE_SIZE sized region starting at physical
address src to the same sized region starting at physical
address dst. The pmap implementation must take whatever
steps are necessary to map the source and destination pages
to a kernel-accessible address and perform the copy. It is
suggested that implementations use an optimized copy algorithm,
as the performance of this function directly impacts
page fault performance. The implementation may assume that
both regions are PAGE_SIZE aligned and exactly PAGE_SIZE
bytes in length.
The same cache considerations that apply to
pmap_zero_page() apply to pmap_copy_page().
void pmap_page_protect(struct vm_page *pg, vm_prot_t prot)
Lower the permissions for all mappings of the page pg to
prot. This function is used by the virtual memory system
to implement copy-on-write (called with VM_PROT_READ set in
prot) and to revoke all mappings when cleaning a page
(called with no bits set in prot). Access permissions must
never be added to a page as a result of this call.
boolean_t pmap_clear_modify(struct vm_page *pg)
Clear the ``modified'' attribute on the page pg.
The pmap_clear_modify() function returns TRUE or FALSE
indicating whether or not the ``modified'' attribute was
set on the page before it was cleared.
Note that this function may be provided as a C pre-processor
macro.
boolean_t pmap_clear_reference(struct vm_page *pg)
Clear the ``referenced'' attribute on the page pg.
The pmap_clear_reference() function returns TRUE or FALSE
indicating whether or not the ``referenced'' attribute was
set on the page before it was cleared.
Note that this function may be provided as a C pre-processor
macro.
boolean_t pmap_is_modified(struct vm_page *pg)
Test whether or not the ``modified'' attribute is set on
page pg.
Note that this function may be provided as a C pre-processor
macro.
boolean_t pmap_is_referenced(struct vm_page *pg)
Test whether or not the ``referenced'' attribute is set on
page pg.
Note that this function may be provided as a C pre-processor
macro.
paddr_t pmap_phys_address(int cookie)
Convert a cookie returned by a device mmap() function into
a physical address. This function is provided to accommodate
systems which have physical address spaces larger than
can be directly addressed by the platform's paddr_t type.
The existence of this function is highly dubious, and it is
expected that this function will be removed from the pmap
API in a future release of NetBSD.
Note that this function may be provided as a C pre-processor
macro.
OPTIONAL FUNCTIONS [Toc] [Back]
This section describes several optional functions in the pmap API.
vaddr_t pmap_steal_memory(vsize_t size, vaddr_t *vstartp, vaddr_t
*vendp)
This function is a bootstrap memory allocator, which may be
provided as an alternative to the bootstrap memory allocator
used within uvm(9) itself. It is particularly useful
on systems which provide e.g. a direct-mapped memory segment.
This function works by stealing pages from the (to
be) managed memory pool, which has already been provided to
uvm(9) in the vm_physmem[] array. The pages are then
mapped, or otherwise made accessible to the kernel, in a
machine-dependent way. The memory must be zeroed by
pmap_steal_memory(). Note that memory allocated with
pmap_steal_memory() will never be freed, and mappings made
by pmap_steal_memory() must never be ``forgotten''.
Note that pmap_steal_memory() should not be used as a general-purpose
early-startup memory allocation routine. It
is intended to be used only by the uvm_pageboot_alloc()
routine and its supporting routines. If you need to allocate
memory before the virtual memory system is initialized,
use uvm_pageboot_alloc(). See uvm(9) for more information.
The pmap_steal_memory() function returns the kernel-accessible
address of the allocated memory. If no memory can be
allocated, or if allocated memory cannot be mapped, the
function must panic.
If the pmap_steal_memory() function uses address space from
the range provided to uvm(9) by the pmap_virtual_space()
call, then pmap_steal_memory() must adjust *vstartp and
*vendp upon return.
The pmap_steal_memory() function is enabled by defining the
C pre-processor macro ``PMAP_STEAL_MEMORY'' in
<machine/pmap.h>.
vaddr_t pmap_growkernel(vaddr_t maxkvaddr)
Management of the kernel virtual address space is complicated
by the fact that it is not always safe to wait for
resources with which to map a kernel virtual address. However,
it is not always desirable to pre-allocate all
resources necessary to map the entire kernel virtual
address space.
The pmap_growkernel() interface is designed to help alleviate
this problem. The virtual memory startup code may
choose to allocate an initial set of mapping resources
(e.g. page tables) and set an internal variable indicating
how much kernel virtual address space can be mapped using
those initial resources. Then, when the virtual memory
system wishes to map something at an address beyond that
initial limit, it calls pmap_growkernel() to pre-allocate
more sources with which to create the mapping. Note that
once additional kernel virtual address space mapping
resources have been allocated, they should not be freed; it
is likely they will be needed again.
The pmap_growkernel() function returns the new maximum kernel
virtual address that can be mapped with the resources
it has available. If new resources cannot be allocated,
pmap_growkernel() must panic.
The pmap_growkernel() function is enabled by defining the C
pre-processor macro ``PMAP_GROWKERNEL'' in
<machine/pmap.h>.
void pmap_fork(pmap_t src_map, pmap_t dst_map)
Some pmap implementations may need to keep track of other
information not directly related to the virtual address
space. For example, on the i386 port, the Local Descriptor
Table state of a process is associated with the pmap (this
is due to the fact that applications manipulate the Local
Descriptor Table directly expect it to be logically associated
with the virtual memory state of the process).
The pmap_fork() function is provided as a way to associate
information from src_map with dst_map when a vmspace is
forked. pmap_fork() is called from uvmspace_fork().
The pmap_fork() function is enabled by defining the C preprocessor
macro ``PMAP_FORK'' in <machine/pmap.h>.
vaddr_t PMAP_MAP_POOLPAGE(paddr_t pa)
This function is used by the pool(9) memory pool manager.
Pools allocate backing pages one at a time. This is provided
as a means to use hardware features such as a directmapped
memory segment to map the pages used by the pool(9)
allocator. This can lead to better performance by e.g.
reducing TLB contention.
PMAP_MAP_POOLPAGE() returns the kernel-accessible address
of the page being mapped. It must always succeed.
The use of PMAP_MAP_POOLPAGE() is enabled by defining it as
a C pre-processor macro in <machine/pmap.h>. If
PMAP_MAP_POOLPAGE() is defined, PMAP_UNMAP_POOLPAGE() must
also be defined.
The following is an example of how to define
PMAP_MAP_POOLPAGE():
#define PMAP_MAP_POOLPAGE(pa) MIPS_PHYS_TO_KSEG0((pa))
This takes the physical address of a page and returns the
KSEG0 address of that page on a MIPS processor.
paddr_t PMAP_UNMAP_POOLPAGE(vaddr_t va)
This function is the inverse of PMAP_MAP_POOLPAGE().
PMAP_UNMAP_POOLPAGE() returns the physical address of the
page corresponding to the provided kernel-accessible
address.
The use of PMAP_UNMAP_POOLPAGE() is enabled by defining it
as a C pre-processor macro in <machine/pmap.h>. If
PMAP_UNMAP_POOLPAGE() is defined, PMAP_MAP_POOLPAGE() must
also be defined.
The following is an example of how to define
PMAP_UNMAP_POOLPAGE():
#define PMAP_UNMAP_POOLPAGE(pa) MIPS_KSEG0_TO_PHYS((va))
This takes the KSEG0 address of a previously-mapped pool
page and returns the physical address of that page on a
MIPS processor.
uvm(9)
The pmap module was originally part of the design of the virtual memory
system in the Mach Operating System. The goal was to provide a clean
separation between the machine-independent and the machine-dependent portions
of the virtual memory system, in stark contrast to the original
3BSD virtual memory system, which was specific to the VAX.
Between 4.3BSD and 4.4BSD, the Mach virtual memory system, including the
pmap API, was ported to BSD and included in the 4.4BSD release.
NetBSD inherited the BSD version of the Mach virtual memory system.
NetBSD 1.4 was the first NetBSD release with the new uvm(9) virtual memory
system, which included several changes to the pmap API. Since the
introduction of uvm(9), the pmap API has evolved further.
The original Mach VAX pmap module was written by Avadis Tevanian, Jr. and
Michael Wayne Young.
Mike Hibler did the integration of the Mach virtual memory system into
4.4BSD and implemented a pmap module for the Motorola
68020+68851/68030/68040.
The pmap API as it exists in NetBSD is derived from 4.4BSD, and has been
modified by
Chuck Cranor,
Charles M. Hannum,
Chuck Silvers,
Wolfgang Solfrank,
Bill Sommerfeld, and
Jason R. Thorpe.
The author of this document is
Jason R. Thorpe <[email protected]>.
The use and definition of pmap_activate() and pmap_deactivate() needs to
be reexamined.
The use of pmap_copy() needs to be reexamined. Empirical evidence suggests
that performance of the system suffers when pmap_copy() actually
performs its defined function. This is largely due to the fact that the
copy of the virtual-to-physical mappings is wasted if the process calls
execve(2) after fork(2). For this reason, it is recommended that pmap
implementations leave the body of the pmap_copy() function empty for now.
BSD August 14, 2002 BSD
[ Back ] |
