Re: Tracking of the accessed bit in vptes

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hello,
:
: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.
:
:Aggelos

    That's reasonably accurate.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>