On 7 October 2016 at 02:43, Michel Dänzer <michel.daen...@mailbox.org> wrote: > On 07/10/16 05:44 AM, Eric Anholt wrote: >> Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
