support booting with more than 4G of memory#2361
support booting with more than 4G of memory#2361mazunki wants to merge 7 commits intoincludeos:mainfrom
Conversation
|
Note that this solution isn't perfect: LiveUpdate and other components should be made dynamic and cooperate somehow with selecting the heap's size. The preemptive support of unassigning memory map ranges aims to facilitate this transition. |
|
Integration tests are currently unable to run Pending introducing integration tests for differently sized |
MagnusS
left a comment
MagnusS
left a comment
There was a problem hiding this comment.
Looks good, but some smaller comments inline :-) Thanks!
The multiboot specification explicitly states that `mem_upper` is not guaranteed to be the correct value for mem_upper. Additionally, placing the heap in-between `mem_lower` and `mem_upper` only really makes sense on 32-bit systems. By using memory mapped pages we can pick the largest consecutive region of memory available. Selecting 1_000_000 as the minimum address is a temporary hack since it's not immediately obvious how to get the correct address for virtual mappings that are still not initialized (such as LiveUpdate and SystemLog). The correct solution here would be to make these regions dynamic in size, initialize them earlier so the regions are already claimed, or re-initialize the heap. This is only necessary for systems that have less than 4G of memory. See-Also: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html See-Also: https://wiki.osdev.org/Multiboot
This will permit repurposing an already assigned mapping, allowing multiboot to preemptively assigning "free memory" regions, resizing ranges by deleting and recreating them, or making temporary regions. Could also be useful for NUMA.
|
Integration tests have been added. This should be ready to be merged now (after #2363). Some of the tests are in a half-disabled state currently because the upstream buddy allocator doesn't support large allocations. The integration itself requires 6 GiB on the system currently: anything less wouldn't really make sense for this test. 16 GiB tests are desired cuz it seems like buddy breaks apart after around a 8GiB limit. Note:
|
2 participants
This PR adds support for booting IncludeOS with more than 4 GB of physical memory, updating the example unikernel's message to show these mappings. Before this PR, the max size of the heap would be ~2.2GiB.
The old example unikernel wasn't terribly useful: maybe we could extend the example unikernel to be informative of more aspects of the kernel's state after it has been booted?
It additionally adds preemptive supports to unassigning virtual mappings, and shuts down the unikernel if a strace condition has been hit.
See full commit messages for specific details.