arm: tune vmparam.h towards a little more modern

[kevans]

Summary

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).

[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 https://cgit.freebsd.org/src/tree/sys/vm/vm_mmap.c#n1641 need some sort of fallback mechanism (something like backward search from original vm_daddr + lim_max(td, RLIMIT_DATA )).

[kib]

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

[kevans]

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.

[kib]

512M for data is reasonable.