Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I don't know what is going on here, but recording since something is wrong.
When I use
The only obvious difference is that
@ianlancetaylor I investigated this with someone who knows OpenBSD a bit.
The number that's checked in the kernel from a
Perhaps there's a workaround here but I need to give it some thought.
It's a little bit weird to me that a
It's been a while since I've looked at OpenBSD's mmap implementation. I seem to recall it took the stance that PROT_NONE mappings still mapped data (and thus counts towards RLIMIT_DATA), just without read/write access.
I see that http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/go/Makefile?rev=1.75 uses
Currently the page allocator bitmap is implemented as a single giant memory mapping which is reserved at init time and committed as needed. This causes problems on systems that don't handle large uncommitted mappings well, or institute low virtual address space defaults as a memory limiting mechanism. This change modifies the implementation of the page allocator bitmap away from a directly-mapped set of bytes to a sparse array in same vein as mheap.arenas. This will hurt performance a little but the biggest gains are from the lockless allocation possible with the page allocator, so the impact of this extra layer of indirection should be minimal. In fact, this is exactly what we see: https://perf.golang.org/search?q=upload:20191125.5 This reduces the amount of mapped (PROT_NONE) memory needed on systems with 48-bit address spaces to ~600 MiB down from almost 9 GiB. The bulk of this remaining memory is used by the summaries. Go processes with 32-bit address spaces now always commit to 128 KiB of memory for the bitmap. Previously it would only commit the pages in the bitmap which represented the range of addresses (lowest address to highest address, even if there are unused regions in that range) used by the heap. Updates #35568. Updates #35451. Change-Id: I0ff10380156568642b80c366001eefd0a4e6c762 Reviewed-on: https://go-review.googlesource.com/c/go/+/207497 Run-TryBot: Michael Knyszek <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Austin Clements <firstname.lastname@example.org> Reviewed-by: Cherry Zhang <email@example.com>
The login class will be the reason why the allocation worked when run as root, but not when run as a normal user. However, even when a user has
The same failure could also be triggered under Linux via
Obviously this was a pretty significant regression from Go 1.13 - I can confirm that with the sparse array change, I can once again build Go with a data size limit of 2GB (although there appears to have been another regression with the memory requirements for compiling