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

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 28579
Build 26623: arc lint + arc unit

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
1396–1397

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

1401

Do we need to dump_add_page()?

1404

I think you need to handle M_ZERO here.

1417

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.

1421–1438

Extra newline.

2539

We ought to be able to use M_ZERO instead.

sys/vm/uma_core.c
1396–1397

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.

1401

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

1417

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

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.