Page MenuHomeFreeBSD

pmap: standardize promotion conditions between amd64 and arm64

Authored by alc on Oct 8 2022, 5:57 PM.
Referenced Files
Unknown Object (File)
Sun, Mar 5, 5:58 PM
Unknown Object (File)
Feb 17 2023, 4:29 PM
Unknown Object (File)
Feb 17 2023, 4:29 PM
Unknown Object (File)
Feb 17 2023, 4:29 PM
Unknown Object (File)
Jan 9 2023, 4:15 AM
Unknown Object (File)
Jan 9 2023, 2:36 AM
Unknown Object (File)
Dec 15 2022, 8:07 PM
Unknown Object (File)
Dec 15 2022, 5:15 PM



On amd64, don't abort promotion due to a missing accessed bit in a
mapping before possibly write protecting that mapping. Previously,
in some cases, we might not repromote after madvise(MADV_FREE) because
there was no write fault to trigger the repromotion. Conversely, on
arm64, don't pointlessly, yet harmlessly, write protect physical pages
that aren't part of the physical superpage.

Don't count aborted promotions due to explicit promotion prohibition
(arm64) or hardware errata (amd64) as ordinary promotion failures.

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

alc requested review of this revision.Oct 8 2022, 5:57 PM
alc edited the summary of this revision. (Show Details)

As an aside, in a few weeks, I may eliminate the requirement that PG_A/ATTR_AF is set, add a call to pmap_promote_{pde,l2}() from pmap_enter_quick_locked(), and change pmap_advise(MADV_FREE) to simply write protect one 4KB mapping after demotion (rather than destroying it).


I don't quite understand the problem being solved. Are we simply trying to minimize the window in which a concurrent access sets PG_A after pmap_promote_pde() has loaded a copy of the PTE? The use of the word "must" in the comment above makes me think I'm missing something.


Suppose that madvise(MADV_FREE) is applied to a portion of a superpage. Let's call that portion [S, E). The madvise(MADV_FREE) will demote the mapping, destroy the 4KB mapping at the end of [S, E), and remove PG_M and PG_A from the rest of the 4KB mappings.

Later, imagine that mailloc() recycles the memory in [S, E), but the last 4KB page in that range is not the last to be rewritten, or simply accessed . In other words, there is a 4KB page, call it P, in [S, E), that is still writeable, but PG_M and PG_A are still clear. Previously, seeing that PG_A is clear on P during an attempted promotion when the last 4KB page in [S, E) is written, we would have aborted the promotion without write protecting P. Then, if and when P is finally rewritten, there won't be a page fault to trigger repromotion.


I must admit that this text is much more useful then the added code comment.

This revision is now accepted and ready to land.Oct 10 2022, 1:54 PM
This revision now requires review to proceed.Oct 10 2022, 5:12 PM
This revision is now accepted and ready to land.Oct 10 2022, 8:53 PM