Page MenuHomeFreeBSD

amd64: Add comments to pmap_pinit_type()
ClosedPublic

Authored by markj on Oct 16 2021, 10:00 PM.
Tags
None
Referenced Files
F106135595: D32528.id96968.diff
Wed, Dec 25, 11:56 PM
F106107499: D32528.diff
Wed, Dec 25, 12:48 PM
Unknown Object (File)
Wed, Dec 11, 1:20 AM
Unknown Object (File)
Wed, Nov 27, 3:13 AM
Unknown Object (File)
Nov 23 2024, 11:18 AM
Unknown Object (File)
Nov 17 2024, 3:32 AM
Unknown Object (File)
Nov 14 2024, 8:35 AM
Unknown Object (File)
Nov 14 2024, 6:50 AM
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.