Page MenuHomeFreeBSD

arm: tune vmparam.h towards a little more modern

Authored by kevans on Nov 14 2020, 7:17 PM.
Referenced Files
Unknown Object (File)
Sat, May 25, 8:33 PM
Unknown Object (File)
Sat, May 25, 8:04 PM
Unknown Object (File)
Mon, May 20, 5:57 AM
Unknown Object (File)
Sun, May 19, 5:30 PM
Unknown Object (File)
Sat, May 11, 8:50 PM
Unknown Object (File)
Sat, May 11, 8:50 PM
Unknown Object (File)
Sat, May 11, 8:32 PM
Unknown Object (File)
Sat, May 11, 7:14 PM



An 8MB max stack size is quite limiting in today's world, and in-fact is the *default* stack size for almost every other arch (including mips).

Raise the default to 4MB (should be pretty reasonable) and the max to 64MB. NetBSD made a similar move back in 2015 and raised MAXDSIZ to 1856 at the same time, so let's just roll that in as well. They later lowered it, but eventually raised it back to 1856 in order to build rust.

This was noticed while looking at qemu-bsd-user's default stack sizes and growth behavior (or lack thereof).

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Nov 15 2020, 6:21 PM
mmel added a subscriber: mmel.

Unfortunately, side effect of this is large reduction of VA space available for mmap -> available range for (unfixed) mmap is only in the interval <start of data segment + MAXDSIZ, end of user VA space>.

Kib, I think that computation of minimal address in need some sort of fallback mechanism (something like backward search from original vm_daddr + lim_max(td, RLIMIT_DATA )).

On i386 (with full 4G UVA) MAXDSIZ is 512M. I think it is more reasonable value than 1.5G.

FWIW, I do not have a strong feeling about the data size. This was taken as a hint from NetBSD with insufficient research into the impact... as long as the stack size part of this change is still reasonable (my testing with qemu-user seems to indicate that it is) then I am happy to leave MAXDSIZ reverted.

512M for data is reasonable.