https://bugzilla.redhat.com/show_bug.cgi?id=1457929 --- Comment #19 from Pavel Raiskup <praiskup@xxxxxxxxxx> --- 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx