Page MenuHomeFreeBSD

Don't preallocate boot pages for UMA.
ClosedPublic

Authored by jeff on Jan 9 2020, 10:02 AM.

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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jeff created this revision.Jan 9 2020, 10:02 AM
jeff edited the summary of this revision. (Show Details)Jan 9 2020, 10:06 AM
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.
markj added inline comments.Jan 9 2020, 5:16 PM
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.

jeff added inline comments.Jan 9 2020, 6:49 PM
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.

jeff updated this revision to Diff 66570.Jan 9 2020, 7:31 PM

Review feedback. Some further simplifications of startup handling.

jeff marked 4 inline comments as done.Jan 9 2020, 7:33 PM
glebius accepted this revision.Jan 9 2020, 11:17 PM
This revision is now accepted and ready to land.Jan 9 2020, 11:17 PM
glebius added inline comments.Jan 9 2020, 11:18 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.

markj accepted this revision.Jan 11 2020, 12:10 AM
jeff added a comment.Jan 11 2020, 12:19 AM

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.

markj added a comment.Jan 12 2020, 8:41 PM
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.