[Bug 274705] unreasonably large stack reservation for armv7 processes on arm64
Date: Tue, 24 Oct 2023 22:02:53 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274705
Bug ID: 274705
Summary: unreasonably large stack reservation for armv7
processes on arm64
Product: Base System
Version: 13.2-STABLE
Hardware: arm64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: arm
Assignee: freebsd-arm@FreeBSD.org
Reporter: fuz@FreeBSD.org
CC: cognet@FreeBSD.org, kib@FreeBSD.org
Attachment #245854 text/plain
mime type:
Flags: mfc-stable13?, mfc-stable14?
Created attachment 245854
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=245854&action=edit
memory-wasting test program
I am trying to understand why armv7 processes on arm64 can only allocate around
2 GB of memory despite being allowed to use the whole 4GB of virtual address
space.
Debugging with kib, we found that 1 GB of address space is reserved for the
stack starting around the 3 GB mark. As mmap() doesn't try to find memory
beyond the stack, this limits it to finding memory between text and stack,
which amounts to around 2 GB.
Running the attached test program, it fails after allocating 2022 buffers @ 1
MB each and we get a memory map like this:
PID START END PRT RES PRES REF SHD FLAG TP PATH
2844 0x10000 0x11000 r-- 1 3 3 1 CN--- vn /usr/home/fuz/test
2844 0x20000 0x21000 r-x 1 3 3 1 CN--- vn /usr/home/fuz/test
2844 0x30000 0x31000 r-- 1 0 1 0 C---- vn /usr/home/fuz/test
2844 0x40000 0x41000 rw- 1 1 1 0 ----- df
2844 0x40040000 0x40045000 r-- 5 29 35 11 CN--- vn /libexec/ld-elf.so.1
2844 0x40045000 0x4004b000 rw- 1 1 1 0 ----- df
2844 0x40054000 0x4006d000 r-x 25 29 35 11 CN--- vn /libexec/ld-elf.so.1
2844 0x4007c000 0x4007d000 r-- 1 0 1 0 C---- vn /libexec/ld-elf.so.1
2844 0x4008c000 0x400af000 rw- 20 20 1 0 ----- df
2844 0x400af000 0x400b3000 r-- 4 14 46 22 CN--- vn /lib/libgcc_s.so.1
2844 0x400b3000 0x400c2000 --- 0 0 0 0 CN--- gd
2844 0x400c2000 0x400cc000 r-x 10 14 46 22 CN--- vn /lib/libgcc_s.so.1
2844 0x400cc000 0x400db000 --- 0 0 0 0 CN--- gd
2844 0x400db000 0x400dc000 rw- 1 0 1 0 C---- vn /lib/libgcc_s.so.1
2844 0x400dc000 0x400eb000 --- 0 0 0 0 CN--- gd
2844 0x400eb000 0x400ec000 rw- 1 0 1 0 C---- vn /lib/libgcc_s.so.1
2844 0x400ec000 0x40133000 r-- 71 360 55 31 CN--- vn /lib/libc.so.7
2844 0x40133000 0x40142000 --- 0 0 0 0 CN--- gd
2844 0x40142000 0x40299000 r-x 282 360 55 31 CN--- vn /lib/libc.so.7
2844 0x40299000 0x402a8000 --- 0 0 0 0 CN--- gd
2844 0x402a8000 0x402ac000 r-- 4 0 2 0 C---- vn /lib/libc.so.7
2844 0x402ac000 0x402ad000 rw- 1 0 2 0 C---- vn /lib/libc.so.7
2844 0x402ad000 0x402bc000 --- 0 0 0 0 CN--- gd
2844 0x402bc000 0x402c1000 rw- 5 0 1 0 C---- vn /lib/libc.so.7
2844 0x402c1000 0x403de000 rw- 272 272 1 0 ----- df
2844 0x40400000 0x68981000 rw- 165235 165235 1 0 ----- df
2844 0x68a00000 0xba916000 rw- 335612 335612 1 0 ----- df
2844 0xbaa00000 0xbff4f000 rw- 20366 20366 1 0 ----- df
2844 0xbfffe000 0xfffde000 --- 0 0 0 0 ----- gd
2844 0xfffde000 0xffffe000 rw- 3 3 1 0 ---D- df
2844 0xffffe000 0xfffff000 r-x 1 1 161 0 ----- ph
clearly showing how a large guard mapping for the stack from 0xbfffe000 to
0xfffde000 prevents the heap from growing further. On the other side, mmap()
doesn't want to allocate below 0x40040000, cutting another GB off the available
memory for around 2GB left to allocate.
Setting ulimit -Hs 65536 does not affect the behaviour, but compiling with
-Wl,-z,stack-size=65536 does, reducing the size of the stack mapping.
Perhaps the guard page sizes and mmap lower limits could be adjusted to the
defaults used for i386 processes on amd64 hosts?
--
You are receiving this mail because:
You are the assignee for the bug.