Date: Fri, 20 Apr 2012 20:47:45 +0200 From: Robert Millan <rmh@freebsd.org> To: Peter Wemm <peter@wemm.org> Cc: freebsd-arch@freebsd.org Subject: Re: Increase DFLDSIZ on amd64? Message-ID: <CAOfDtXOqj6ozTSGCiUZ3HCfXwx%2B6aTwtj7bZ1rxQwz32iEb1kA@mail.gmail.com> In-Reply-To: <CAGE5yCqQ=_XysKwQcdu2DUeycp33TzRd0H0FwT-ufitQpGzXPw@mail.gmail.com> References: <CAOfDtXMSQ_iT8zQKjrQ-4AxFDtNoNNj-7-=kXGT6RdOMOtyXUA@mail.gmail.com> <CAGE5yCqQ=_XysKwQcdu2DUeycp33TzRd0H0FwT-ufitQpGzXPw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Peter,
El 19 d’abril de 2012 0:23, Peter Wemm <peter@wemm.org> ha escrit:
> Hmm. In login,conf, we have:
> :datasize=unlimited:
> .. which causes the datasize limit to be pushed to 32G by default at
> login/cron/sshd/etc.
Well, Debian has a similar facility, but I don't think this solves the
problem, as it only covers processes that descend from a login shell.
What about daemons?
> Also, malloc doesn't use this pool on amd64 - it comes straight out of
> mmap MAP_ANON page blocks. The only that should be hitting it ever
> would be things that call the old sbrk(3) interface directly. Malloc
> shouldn't be hitting it.
I hit trouble with the dynamic linker:
# cat test.c
char buf[1024*1024*1024];
int
main ()
{
}
# gcc test.c -o test
# ./test
Abort trap: 6
Not sure about other things but IMHO it's a valid reason to increase
the default to match with the one set by userland.
--
Robert Millan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXOqj6ozTSGCiUZ3HCfXwx%2B6aTwtj7bZ1rxQwz32iEb1kA>