pmap: standardize promotion conditions between amd64 and arm64
ClosedPublic
Actions

Authored by alc on Oct 8 2022, 5:57 PM.

Details

Reviewers

kib
markj
manu

Commits

rGf0878da03b37: pmap: standardize promotion conditions between amd64 and arm64

Summary

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

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

alc created this revision.Oct 8 2022, 5:57 PM

Herald added a reviewer: manu. · View Herald TranscriptOct 8 2022, 5:57 PM

Herald added subscribers: emaste, andrew. · View Herald Transcript

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).

markj added inline comments.Oct 8 2022, 7:03 PM

sys/amd64/amd64/pmap.c
6784	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.

alc added inline comments.Oct 8 2022, 8:59 PM

sys/amd64/amd64/pmap.c
6784	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.