https://bugzilla.redhat.com/show_bug.cgi?id=1457929



--- Comment #19 from Pavel Raiskup <prais...@redhat.com> ---
Hi René, thanks for the comments!

(In reply to René Cannaò from comment #18)
> I am not sure if Fedora should have jemalloc with xmalloc support, as
> upstream intentionally has this option disabled by default.

My opinion about this is that:  jemalloc upstream tries to demotivate from
using the 'xmalloc' feature, but since the option is
still available, and compiling it doesn't hurt the "default" (non-xmalloc)
use-case -- there's no reason to not compile it when some Fedira package
needs it.  It is still better than bundling.

> ProxySQL 1.4.x doesn't just enable xmalloc , but also applies a patch for it
> because by default xmalloc can hurt performance. See:
> * https://github.com/jemalloc/jemalloc/issues/522
> * https://github.com/sysown/proxysql/issues/823
> *
> https://github.com/sysown/proxysql/commit/
> 42a55f750c362299c9f0ed7834cdedc5f9778f47

I can understand this is upstream default for proxysql, but having about 25%
slower allocator (which doesn't mean the whole code is slower by 25%) might be
acceptable for Fedora (and finally, we should do the benchmarking on Fedora to
have the proof that the slowdown affect us).  If we consider the allocator
slow (because some bug report comes), we can patch the default jemalloc
package later on instead of patching one particular package .. that would
mean we ultimately fix all dependent packages, not only proxysql.

Please understand that our work on packages is volunteering effort and we
try clearly separate our responsibilities among distribution.  E.g. in
Fedora, 'jemalloc' is maintained by @ingvar; but we (db team) are
responsible many databases packages.  Additional bundle means taking care
of the bugs, security issues, etc. which is time we could spent elsewhere.

I'm saying that because bundling really hurts us a lot;  and not only us,
this is problem in every distribution out there.  At the end of the day,
it is bad for upstream too (old releases must be marked vulnerable only
because some researcher reveals some serious vulnerability in the bundle).
So we try to motivate upstreams not to bundle *if possible*, or at least
allow us to not bundle downstream (even if that means some acceptable
compromise on our side).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org

Reply via email to