[Mesa-dev] [RFC] ralloc: use jemalloc for faster GLSL compilation

[Emil Velikov]

On 7 October 2016 at 02:43, Michel Dänzer <michel.daenzer at mailbox.org> wrote:
> On 07/10/16 05:44 AM, Eric Anholt wrote:
>> Marek Olšák <maraeo at gmail.com> writes:
>>
>>> I'd like to have more feedback on the idea of using jemalloc for ralloc.
>>>
>>> Right now, I see these options:
>>>
>>> 1) Use jemalloc for ralloc and make it mandatory for all GL drivers.
>>> - Distributions have shown that they are capable of doing anything
>>> with the Mesa source code, so they don't need --disable-jemalloc.
>>> - Reasonable people should build Mesa as-is.
>>>
>>> 2) Abandon the idea.
>>> - The availability of --disable-jemalloc would send a clear message
>>> that "you don't have to enable this", therefore the whole idea of
>>> using jemalloc in Mesa would be pointless.
>>
>> I'm generally of the opinion that if malloc is taking 10% of compile
>> time, we're screwing up and we should just go fix that.  However, this
>> is an easy fix and doesn't prevent going and fixing malloc abuse later.
>
> I haven't seen anybody address the concern which was raised about having
> multiple allocators independently grabbing heap from the kernel (and
> possibly not returning it). Maybe it's not a big deal, but I'd like to
> see at least a brief rationale as to why it's not. Marek, have you
> compared the maximum heap usage with and without jemalloc, e.g. using
> valgrind massif?
>
>
>> I also don't like configure options -- they're mostly a chance to build
>> things wrong.
>
> I think you guys are over-dramatizing this a little. Most distros and
> other users are probably using the defaults of most configure options,
> so we just have to get the default right.
>
Seconded.

While I'm not a huge fan of extra configure toggles and things have
been rough in the past, that shouldn't be the case any more.

>
>> I'm concerned that by shared linking against jemalloc we're going to run
>> into similar problems to every other time we shared link against things
>> and it's going to make our lives harder.  This is probably "we should
>> figure out how to stop shared linking against anything" rather than "we
>> shouldn't make this change", though.
>
> Distros can't just link everything statically, if we try forcing that on
> them they'll just have to revert the damage.
>
Agreed. Let us focus on the code and distros will static/share link
wherever possible/based on their policies.

Memory constrained platforms are places which might want to avoid
linking against jemalloc, at least for the time being. IIRC some
versions [of jemalloc] were "selfish" about returning memory to the
kernel, which can cause lots of fun.


TL;DR: I'm _not_ against using jemalloc (perf. improvement is always
great) but please do _not_ force it onto everyone.

Thanks
Emil