Subject: L1 page table & context switching
To: None <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 08/26/2001 17:33:01
[the following comes from an conversation Chris Dilbert, Reinoud
Zandijk, and I were having today.]
Instead of having a L1 page table per process and swapping them
around on context switches, would it make more sense to have just
one L1 page table and modify its entries on context switches?
Since a process probably only 3-4 PTPs in use (hence L1 entries)
and those are probably common among most processes (executable,
libc, stack), instead of switching to a entirely new L1 page table
we just just swap the few entries that are known.
the following pseudo-code for pmap_activate might help:
if (newpmap == oldpmap)
for each active PTP in the old pmap
invalidate the L1 PDE which points to it
update L1 PDE for new pmap's current stack pointer
update L1 PDE for new pmap's current PC
update <n> L1 PDEs for new pmap's most recently used PTPs
cache_cleanD_SE each L1 PDE
In the page fault handler, if a va is for a L1 PDE which is not
valid, see if there's a PTP for it and if so update L1 PDE to
point to it, and then insert this PTP into the cache of recently
used PTPs. (this could be a small array or a linked list or ...)
For large processes (mozilla :), a copy of the user L1 page table
pages could be kept which could then block moved on activation and
deactivation. This should only be done if the time to copy the PDEs
would be less than updating them individually.
There's a number of advantages to this.
Since only a signle L1 page table exists, there's no need to update
every process'es L1pt on a change in the kernel's L1 PDE entries.
This makes pmap_growkernel much simplier.
No need to allocate 16KB aligned chunks of memory for each pmap's
L1pt (nor to keep that relatively sparsely used memory around).
Matt Thomas Internet: email@example.com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message