Date: Thu, 3 Jan 2008 17:46:14 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no>, Jason Evans <jasone@freebsd.org> Subject: Re: sbrk(2) broken Message-ID: <200801031746.15225.jhb@freebsd.org> In-Reply-To: <477D6078.5030805@samsco.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <477D6078.5030805@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 03 January 2008 05:23:52 pm Scott Long wrote: > Dag-Erling Sm=F8rgrav wrote: > > Jason Evans <jasone@freebsd.org> writes: > >> [sbrk is broken] > >=20 > > The real question is why we would revert perfectly good code (jemalloc) > > from using a modern interface to using one that has been obsolete for > > twenty years, and marked as such in the man page for seven years. > >=20 > > If rwatson@ wants malloc() to respect resource limits, he can bloody > > well fix mmap(). Until he does, the datasize limit is a joke anyway, as > > anyone can circumvent it by either using mmap() instead of malloc() or > > setting _malloc_options before calling malloc(). > >=20 >=20 > That is a pretty damning argument in my mind. Why make such a major=20 > change right before the release when it's effectively useless? The motivation for the change is to preserve POLA as malloc() does honor=20 RLIMIT_DATA in previous releases (4.x, 6.x, etc.). That said, I think=20 RLIMIT_VMEM is probably more useful going forward. I know at work we have= =20 lots of hacks to deal with maxdsiz and trying to allow apps that use large= =20 malloc() and large mmap both cooperate. Having one resource limit for mall= oc=20 + mmap is probably best for the future. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801031746.15225.jhb>