Date: Wed, 31 Jan 2001 20:46:15 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
Cc: arch@FreeBSD.ORG
Subject: Re: Bumping up {MAX,DFL}*SIZ in i386
Message-ID: <Pine.BSF.4.21.0101311926390.8244-100000@besplex.bde.org>
In-Reply-To: <vmhf2g5lrj.wl@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 Jan 2001, Seigo Tanimura wrote:
> I propose the following values for the new user address space
> constraints:
>
> MAXTSIZ and DFLTSIZ: 256MB
> MAXDSIZ and DFLDSIZ: 1.5GB
> MAXSSIZ: 128MB
>
> Total: 1.875G (= 2G - 128M)
>
> MAXTSIZ and DFLTSIZ is bumped as we may want to run a large binary. A
> large binary calls for deep function calls, hence MAXSSIZ is bumped as
> well.
>
> These values are likely to be the final ones for i386 before jumping
> into ia64.
>
> Any comments or flames?
I think these limits shouldn't exist, for the following reasons:
(1) DFLTSIZ already doesn't exist :-).
(2) MAXTSIZ doesn't actually work. It is only used to limit the size
of the initial text section for the aout and gzip image activators,
and in compatibility code. It has no effect for elf text sections
or dynamically loaded text sections.
(3) MAXDSIZ is mainly used to limit the RLIMIT_DATA rlimits even for
root, and together with the other limits, to ensure that the text,
data and stack fit in considerably less than the available address
space so that there is plenty of space to mmap() things. This
should be mostly under application control, and mostly would be
if the rlimits weren't arbitrarily limited.
The details behind (3) show a possible problem with your change.
mmap(0, ...) only allocates data above approx. MAXDSIZ, so increasing
MAXDSIZ from 0.5G to 1.5G breaks mmapping of everything in files of
sizes between about 1.4G and 2.4G (see a recent PR about cmp(1)).
I think mmap(0, ...) should start at vm_daddr + rlim_max_for_data
instead of vm_daddr + MAXDSIZE. Similarly for the elf loader
address (don't load anything that isn't under program control in
the middle of the memory, since this fragments memory).
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101311926390.8244-100000>