Tracking of the accessed bit in vptes
aoiko at cc.ece.ntua.gr
Thu Feb 15 09:34:21 PST 2007
the vkernel's pmap_clear_reference() calls pmap_clearbit(VPTE_A).
pmap_clearbit() will go through the vptes mapping a page and will clear
VPTE_A at line 2730 (line number refer to rev 1.16 of pmap.c). But, as can be
seen at line 2706, the mapping will not be invalidated, because only VPTE_A
is set in "bit". As far as I can tell by grepping, VPTE_A is set only in
pmap_enter() by the vkernel and, on a pagefault, in vm_fault_vpagetable() by
the real kernel. In other words, in order for the A bit to be updated the
mapping must be invalidated first and pmap_clear_reference() won't do that
for us (similarly for pmap_ts_referenced()).
Now, pmap_clear_reference() is only called in vm_pageout_scan() because the
system doesn't care about page references until there's memory pressure
(right?). So, for the vkernel, the pmap_collect() -> pmap_remove_all() call
in the beginning of vm_pageout_scan() is the only thing that makes sure the A
bit wll get updated.
In view of this, is the paragraph below accurate?
Unlike with VPTE_M, the fact that the VPTE_A is not updated by the hardware
doesn't cost us much. The real kernel will also free most of its pagetables
before scanning by vm_page and set PG_A when a page is remapped on a
pagefault (which admittedly is more expensive for the vkernel) so it's not
dependent on hardware support anyway.
More information about the Kernel