Page MenuHomeFreeBSD

amd64: Add comments to pmap_pinit_type()
ClosedPublic

Authored by markj on Oct 16 2021, 10:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 16 2024, 2:50 AM
Unknown Object (File)
Jan 12 2024, 8:52 AM
Unknown Object (File)
Dec 23 2023, 10:11 AM
Unknown Object (File)
Dec 20 2023, 7:29 AM
Unknown Object (File)
Dec 3 2023, 12:28 AM
Unknown Object (File)
Sep 22 2023, 5:22 PM
Unknown Object (File)
Jul 21 2023, 3:29 AM
Unknown Object (File)
Jul 11 2023, 10:16 PM
Subscribers

Details

Summary

... explaining why we don't pass the pmap pointer to
pmap_alloc_pt_page().

Reported by: alc

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Update the comment to mention the real reason for not counting
the root page(s).

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.

This revision is now accepted and ready to land.Oct 17 2021, 9:22 PM

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.

I will work on the accounting patch after this one lands.

This revision was automatically updated to reflect the committed changes.