Add GASMAN workaround for fewer than 48-bits of addressable memory (riscv) - #6522
Add GASMAN workaround for fewer than 48-bits of addressable memory (riscv)#6522orlitzky wants to merge 2 commits into
Conversation
On riscv, there may not be the full 48 bits of addressable virtual memory that GASMAN is expecting. To facilitate workarounds for this, we add a new ./configure check to detect an SV39 MMU: https://docs.kernel.org/arch/riscv/vm-layout.html The check is skipped if we are cross-compiling, or if the host architecture is anything other than riscv64. The check itself consists of a small C program that queries the Linux kernel for the largest supported virtual address: https://docs.kernel.org/arch/riscv/hwprobe.html Naturally, the check requires Linux to function. If it succeeds, a new preprocessor constant HAVE_SV39_MMU is defined. If it fails, or if it is skipped, we do nothing.
Many 64-bit RISC-V machines have an MMU that supports only 39 bits of addressable virtual memory. On Linux, this is limited to 38 bits: https://docs.kernel.org/arch/riscv/vm-layout.html When GASMAN initially allocates its pool, it suggests to mmap() that the pool should be offset by 16TB to avoid collision with subsequent mallocs. This request is honored, even when only 38 bits are usable, by putting the pool at the end of addressable memory: gap-packages/images#41 This can lead to GASMAN thinking that is has run out of memory on such a system if it later tries to enlarge the pool. The ./configure script is now capable of detecting these RISC-V systems. When one is found, we provide an offset of 96GB instead. This has proved much more reliable in testing.
| /* On Linux (the only place we check for it), this MMU can only | ||
| * address 38 bits of virtual memory. The hint supplied to mmap() | ||
| * therefore needs to be much smaller than the default 16TB. Trial | ||
| * and error shows that 96GB works well enough. */ |
There was a problem hiding this comment.
That's on your 128 GB machine though, isn't it? But will it still work if run in e.g. a 16 GB machine, or a 256 GB machine?
There was a problem hiding this comment.
This is only the offset within the virtual space and should not depend on the amount of physical RAM in the system. (I certainly don't have 16TB installed on the x86_64 box.)
I first tried 128GB (the halfway point in my VM space) but 96GB allowed me to extend the workspace much further. There is a trade-off between how much space to reserve for GASMAN vs. how much to leave for extensions to malloc. By choosing 96GB, I am limiting extensions to 96GB of usable RAM even though the machine has more available. But presently I find that less likely than the 100% chance that the images test suite wants to allocate 128GB.
The fact that this box has so much RAM on an SV39 MMU is an oddity. I don't know what the board designers were thinking, but the firmware is limited to 128GB, and I would guess that future boards (that can handle more physical RAM) will have more capable MMUs.
2 participants
Add a
./configurecheck to detect an SV39 MMU on RISC-V hardware, and supply a better hint for GASMAN's initialmmap()when one is found.Tested on riscv64/musl (patch works) and x86_64/glibc (nothing changes).
Closes: gap-packages/images#41