Page MenuHomeFreeBSD

Don't preallocate boot pages for UMA.
ClosedPublic

Authored by jeff on Jan 9 2020, 10:02 AM.
Tags
None
Referenced Files
F105956120: D23102.id.diff
Mon, Dec 23, 2:22 AM
Unknown Object (File)
Sat, Dec 21, 2:17 AM
Unknown Object (File)
Thu, Dec 5, 9:08 AM
Unknown Object (File)
Tue, Dec 3, 6:26 AM
Unknown Object (File)
Nov 1 2024, 5:45 PM
Unknown Object (File)
Oct 26 2024, 6:38 PM
Unknown Object (File)
Oct 4 2024, 3:36 PM
Unknown Object (File)
Oct 4 2024, 8:00 AM
Subscribers

Details

Summary

Get out of the business of counting pages for startup memory.

When I first wrote the allocator boot pages was actually just a bss array. At some point we moved it into vm_page_init so it could be dynamically allocated. This was really only done to grab kva and physical memory before it was inserted into the phys allocator and virtual memory before it ended up in the vm_map. vm_page_startup() does not actually need UMA for anything.

What this does instead is to simply allocate and map as we go. It still uses pmap_map(). It has to mark the virtual address space consumed before any other kva allocation proceeds and we can't free it with the normal kmem_free(). We can, however, free the pages if they become available after boot, however unlikely that may be.

Test Plan

I have not yet tested on any !DMAP architecture.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jeff edited the test plan for this revision. (Show Details)
jeff added reviewers: rlibby, markj, glebius, alc.
jeff set the repository for this revision to rS FreeBSD src repository - subversion.
sys/vm/uma_core.c
1414 ↗(On Diff #66544)

Isn't this redundant with the code below? That is, on direct map architectures pmap_map() doesn't do anything.

1419 ↗(On Diff #66544)

Do we need to dump_add_page()?

1422 ↗(On Diff #66544)

I think you need to handle M_ZERO here.

1435 ↗(On Diff #66544)

Don't we need to make some effort to unmap the page on non-direct map architectures? The page might later be mapped using a non-default caching mode, and some processors do not support having mapping aliases with different modes.

1437 ↗(On Diff #66544)

Extra newline.

2512 ↗(On Diff #66544)

We ought to be able to use M_ZERO instead.

sys/vm/uma_core.c
1414 ↗(On Diff #66544)

Yes but it can be routed back through the normal free path. I probably don't even need this sort-circuit here. I can just assign this unconditionally in zone_ctor now and only use startup for multi-page.

1419 ↗(On Diff #66544)

Yeah you are right. I should mostly just copy the code in uma_small_alloc().

1435 ↗(On Diff #66544)

I suspect that even on those processors it will be harmless if you don't access it. But yes, it would be better to unmap. I just wasn't 100% sure which pmap call was right for !DMAP architectures.

Review feedback. Some further simplifications of startup handling.

jeff marked 4 inline comments as done.Jan 9 2020, 7:33 PM
This revision is now accepted and ready to land.Jan 9 2020, 11:17 PM
sys/vm/uma_core.c
1411 ↗(On Diff #66570)

IMHO, easier to read when whole cycle is under #ifdef rather than only its body.

Any volunteers to test on i386?

In D23102#506936, @jeff wrote:

Any volunteers to test on i386?

I just kicked off an update on an i386 laptop, I can try after that's done (probably not before tomorrow though). I think Peter is set up to test i386 kernels too.

In D23102#506936, @jeff wrote:

Any volunteers to test on i386?

I just kicked off an update on an i386 laptop, I can try after that's done (probably not before tomorrow though). I think Peter is set up to test i386 kernels too.

It boots fine for me.