Page MenuHomeFreeBSD

pmap: standardize promotion conditions between amd64 and arm64
ClosedPublic

Authored by alc on Oct 8 2022, 5:57 PM.
Tags
None
Referenced Files
F102428620: D36916.id111585.diff
Tue, Nov 12, 3:42 AM
Unknown Object (File)
Tue, Oct 29, 12:22 AM
Unknown Object (File)
Sun, Oct 20, 11:31 AM
Unknown Object (File)
Oct 3 2024, 8:02 PM
Unknown Object (File)
Oct 3 2024, 8:18 AM
Unknown Object (File)
Oct 1 2024, 8:57 AM
Unknown Object (File)
Oct 1 2024, 5:04 AM
Unknown Object (File)
Sep 29 2024, 12:10 AM
Subscribers

Details

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

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
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).

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.

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.

sys/amd64/amd64/pmap.c
6784

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