Increase DFLDSIZ on amd64?

[Robert Millan-2]

Hi,

Is there any reason for DFLDSIZ being so low (128 MiB) on amd64?
We've recently had a bunch of trouble in Debian when attempting to run
the CMOR testsuite.  Its testcases require about ~700 MiB to pass.  We
also found references recommending higher values for applications like
SAP [2] or MySQL [3].

I understand on i386 there's a shortage of virtual memory, but on
amd64 there's plenty of it.  It seems this is already reflected on the
MAXDSIZ setting (32 GiB), but DFLDSIZ is still the same as on i386.
Wouldn't 32 GiB be a sound value as the default limit too?  Is there
any unreasonable cost or security consideration associated with
allocating so many pages?

Thanks

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661283
[2] http://www.freebsd.org/doc/handbook/sapr3.html#KERNELTUNING
[3] https://dev.mysql.com/doc/refman/5.0/en/freebsd.html

--
Robert Millan

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Peter Wemm-2]

On Wed, Apr 18, 2012 at 2:41 PM, Robert Millan <[hidden email]> wrote:

> Hi,
>
> Is there any reason for DFLDSIZ being so low (128 MiB) on amd64?
> We've recently had a bunch of trouble in Debian when attempting to run
> the CMOR testsuite.  Its testcases require about ~700 MiB to pass.  We
> also found references recommending higher values for applications like
> SAP [2] or MySQL [3].
>
> I understand on i386 there's a shortage of virtual memory, but on
> amd64 there's plenty of it.  It seems this is already reflected on the
> MAXDSIZ setting (32 GiB), but DFLDSIZ is still the same as on i386.
> Wouldn't 32 GiB be a sound value as the default limit too?  Is there
> any unreasonable cost or security consideration associated with
> allocating so many pages?

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.

128M is too small, but I'm curious about how this would be getting
exposed to users.  All the setusercontext() stuff should be fixing
that, and if not then something is missing.

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.

--
Peter Wemm - [hidden email]; [hidden email]; [hidden email]; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Robert Millan-2]

Hi Peter,

El 19 d’abril de 2012 0:23, Peter Wemm <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Konstantin Belousov]

On Fri, Apr 20, 2012 at 08:47:45PM +0200, Robert Millan wrote:

> Hi Peter,
>
> El 19 d???abril de 2012 0:23, Peter Wemm <[hidden email]> 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.

Just for record, this is not an issue with dynamic linker.
Kernel image activator returns error if data segment size is larger
then RLIMIT_DATA value, see imgact_elf.c:901.

Then, since the address space of the program which called execve(2)
is already destroyed when segment mapping is performed, kernel has no
other choice and kills the process.

[Robert Millan-2]

El 20 d’abril de 2012 20:55, Konstantin Belousov <[hidden email]>
ha escrit:
> Just for record, this is not an issue with dynamic linker.
> Kernel image activator returns error if data segment size is larger
> then RLIMIT_DATA value, see imgact_elf.c:901.

I see.  So if it can't be handled gracefully in userland, the more
reason to avoid it...

Is there any objection to increasing DFLDSIZ as proposed?

--
Robert Millan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"