On Jan 3, 2008, at 3:46 PM, John Baldwin wrote:

quoted text
> On Thursday 03 January 2008 05:23:52 pm Scott Long wrote:
>> Dag-Erling Smørgrav wrote:
>>> Jason Evans <jasone@freebsd.org> writes:
>>>> [sbrk is broken]
>>>
>>> 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.
>>>
>>> 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().
>>>
>>
>> That is a pretty damning argument in my mind.  Why make such a major
>> change right before the release when it's effectively useless?
>
> The motivation for the change is to preserve POLA as malloc() does  
> honor
> RLIMIT_DATA in previous releases (4.x, 6.x, etc.).  That said, I think
> RLIMIT_VMEM is probably more useful going forward.  I know at work  
> we have
> lots of hacks to deal with maxdsiz and trying to allow apps that use  
> large
> malloc() and large mmap both cooperate.  Having one resource limit  
> for malloc
> + mmap is probably best for the future.
>

If it were happening on a stable branch, I'd agree more with the POLA  
argument.
The tradeoff between last minute destabilization, which is exactly  
what happened
here, and the highly imperfect and antiquated justification, is pretty  
bogus.

Scott

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"