Page MenuHomeFreeBSD

Fix some nits in 1G page handling.
ClosedPublic

Authored by markj on Sep 17 2020, 4:34 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 28, 5:15 PM
Unknown Object (File)
Mon, Oct 28, 5:13 PM
Unknown Object (File)
Mon, Oct 28, 5:09 PM
Unknown Object (File)
Mon, Oct 28, 5:09 PM
Unknown Object (File)
Oct 22 2024, 7:34 PM
Unknown Object (File)
Oct 22 2024, 10:40 AM
Unknown Object (File)
Oct 22 2024, 10:40 AM
Unknown Object (File)
Oct 22 2024, 10:40 AM
Subscribers

Details

Summary
  • Move assertions out of the main loop. This makes the assertion condition simpler and makes the code easier to follow IMO.
  • Fix va_next updates. In some cases we were not doing the wraparound check before continuing the loop.
  • Use the right va_next. In pmap_advise() and pmap_copy() we would step through 1G pages 2M at a time.
  • Write "non-transparent" instead of "non-transient" in the assertion message. I believe this was the original intent.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 33627
Build 30870: arc lint + arc unit

Event Timeline

markj requested review of this revision.Sep 17 2020, 4:34 PM
markj created this revision.
This revision is now accepted and ready to land.Sep 17 2020, 5:12 PM
sys/amd64/amd64/pmap.c
5946

Shouldn't this really say something like, "partial removal of non-transparent 1G mapping "? The key word being "partial".

5951

There is an extra space here.

6237

Ditto.

7381

Ditto.

7531

Why aren't we copying the mapping here?

8590

Ditto.

markj added inline comments.
sys/amd64/amd64/pmap.c
5946

I changed it to "partial update of non-transparent 1G mapping" in all places.

7531

I don't think there is any reason not to do it.

markj marked an inline comment as done.

Implement handling for 1G pages in pmap_copy().

This revision now requires review to proceed.Sep 18 2020, 4:52 PM

Hm, unless I miss something, does pmap_copy() break MINHERIT_ZERO ?

In D26463#589164, @kib wrote:

Hm, unless I miss something, does pmap_copy() break MINHERIT_ZERO ?

From my reading, pmap_copy() is only used for VM_INHERIT_COPY and _SHARED.

In D26463#589164, @kib wrote:

Hm, unless I miss something, does pmap_copy() break MINHERIT_ZERO ?

From my reading, pmap_copy() is only used for VM_INHERIT_COPY and _SHARED.

Right, pmap_copy() is only called per map entry.

This revision is now accepted and ready to land.Sep 18 2020, 6:26 PM
This revision was automatically updated to reflect the committed changes.
head/sys/amd64/amd64/pmap.c
6504 ↗(On Diff #77221)

Can't pmap_pml4e() now return NULL under LA57?

6528 ↗(On Diff #77221)

I don't understand why we do this unconditionally. We don't use mp except in the then clause of the below if statement.

6536 ↗(On Diff #77221)

Using PG_FRAME here will include X86_PG_PDE_PAT in the compared bits.

6566 ↗(On Diff #77221)

Ditto.

6572 ↗(On Diff #77221)

Ditto.

6582 ↗(On Diff #77221)

I find it curious that the resident count is handled one way and the wired count another way.

head/sys/amd64/amd64/pmap.c
6221 ↗(On Diff #77221)

Can't pmap_pml4e() now return NULL under LA57?

head/sys/amd64/amd64/pmap.c
6221 ↗(On Diff #77221)

Yes this is systematic error. D26492.

markj added inline comments.
head/sys/amd64/amd64/pmap.c
6536 ↗(On Diff #77221)

I believe we can actually make this assertion stronger and write

KASSERT((origpte & PG_V) == 0 || ((origpte ^ pten) & ~(PG_W | PG_M)) == 0, (...));
head/sys/amd64/amd64/pmap.c
6536 ↗(On Diff #77221)

Why PG_RW or PG_NX cannot change ? And I am not sure about PAT.