runtime: large address space footprint on 32-bit linux #35677
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?Summary
Running a simple golang program on linux/arm (or other 32-bit linux arch) shows ~800MB of the virtual address space is reserved up front:
The Linux kernel can be compiled with one of three different vmsplit modes: VMSPLIT_3G, VMSPLIT_2G, VMSPLIT_1G
I have a golang program that makes heavy use of memory mapped files, and runs on ARM appliances where the vendor has compiled their kernel with VMSPLIT_2G. Since the golang runtime reserves 40% of the available address space up-front, my program is limited in the amount of files it can
mmap
for its own purposes. When the address space is exhausted, bad things happen including panics when trying to spawn threads:The golang runtime documents its memory mappings in malloc.go. The ~800MB reserved is made up of two large reservations: the first is ~258MB and the second is 512MB.
go/src/runtime/malloc.go
Lines 541 to 545 in a23f9af
go/src/runtime/malloc.go
Lines 551 to 552 in a23f9af
The 512MB initial reservation can be tweaked with a patch to
arenaSizes
:go/src/runtime/malloc.go
Lines 586 to 592 in a23f9af
However, it is not clear to me how I can reduce the ~258MB reservation. The code comment states "We could reserve a smaller amount of space up front if this is problem.", so I'm looking for some guidance on how to do this.
Since userspace on 32-bit linux can access a maximum of 3GB of memory (when the kernel is compiled with
VMSPLIT_3G
[which is the default]), it seems like at the very least the 258MB reservation could be reduced by 1/4 to ~198MB.cc @aclements
The text was updated successfully, but these errors were encountered: