DragonFly kernel List (threaded) for 2007-02
DragonFly BSD
DragonFly kernel List (threaded) for 2007-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Tracking of the accessed bit in vptes

From: Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>
Date: Thu, 15 Feb 2007 19:12:23 +0200


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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]