... explaining why we don't pass the pmap pointer to
pmap_alloc_pt_page().
Reported by: alc
Differential D32528
amd64: Add comments to pmap_pinit_type() markj on Oct 16 2021, 10:00 PM. Authored by Tags None Referenced Files
Subscribers
Details
... explaining why we don't pass the pmap pointer to Reported by: alc
Diff Detail
Event TimelineComment Actions I think it is fine for now, but ultimately I would probably work on accounting root page table pages and fixing pmap_remove() to check for number of root pages instead of zero. This should be relatively simple. Comment Actions I strongly suspect that the introduction of kern_exec.c's shared page in every address space rendered pmap_remove()'s early termination optimization completely ineffective. (Keep in mind that the shared page belongs to an OBJT_PHYS object, so the shared page has an unmanaged mapping.) Once upon a time, almost all user address spaces would have consisted of nothing but managed mappings. And, when terminating a user address space, pmap_remove_pages() would have destroyed all of those mappings before any calls to pmap_remove() occurred from vm_map_delete(). In other words, the pmap's resident count would have been zero before any of those calls to pmap_remove(), so they would have terminated before even acquiring the pmap lock. Now, the shared page mapping stops that. |