DragonFly kernel List (threaded) for 2007-02
Re: Tracking of the accessed bit in vptes
: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()).
This is correct. I decided not to try to track the 'A'ccess bit the
same way I track the 'M'odified bit due to the excessive number of
page faults that would occur.
: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.
That's reasonably accurate.