Hello Mauricio, or anyone else affected, Accepted glibc into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/glibc/2.35-0ubuntu3.12 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: glibc (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-jammy -- You received this bug notification because you are a member of Debcrafters packages, which is subscribed to glibc in Ubuntu. https://bugs.launchpad.net/bugs/2089789 Title: malloc performance degradation with CPU affinity masks Status in glibc package in Ubuntu: Fix Released Status in glibc source package in Jammy: Fix Committed Bug description: [Impact] * Jammy has a malloc() performance degradation if CPU affinity masks are used (not default). * The maximum number of arenas for malloc() is calculated based on the number of processors. However, glibc 2.34 changed that to be based on sched_getaffinity(), which is the number of processors available _to the process_ (i.e., based on CPU affinity masks). [0] Previously, glibc 2.33 instead used the of processors available _in the system_ (i.e., based on sysfs and procfs files). * This is not an issue by default, as without CPU affinity masks, the returned number of processors is the same as sysfs and procfs. But it _is_ an issue if CPU affinity masks are set, as it can increase lock contention (less arenas), and thus degrade performance. * CPU affinity can be set at the process-level (e.g., taskset, numactl, sched_setaffinity()) or at the system-level (kernel boot options). The latter is common in hypervisor and/or DPDK deployments, where CPU partitioning is applied with isolcpus, cpusets, systemd's CPUAffinity. [Test Plan] * The upstream bug report [1] has a reproducer, used in comment #5 to reproduce the problem, and in comment #6 to validate the fix patch. It is copied/attached to this bug as backup (test-glibc-malloc.c). The expected behavior is that these 2 steps (measuring the average time taken by 50.000 malloc+free calls, with one thread per CPU) take similar amounts of time with & without CPU affinity masks (parameter 2: true/false), in a system with a great number of CPUs. $ ./test-glibc-malloc $(nproc) false false $ ./test-glibc-malloc $(nproc) true false * glibc has a build-time test suite. * glibc has autopkgtests (rebuild, ie, above) and triggers autopkgtests in a great number of reverse test dependencies. [Regression Potential] * Theoretically, any fallout should be contained in malloc() and be related only to performance, not to functional errors. * This happens because this malloc() patch [2] changes only which method to get the number of processors. * The method it changes to is what has been already used by previous versions of glibc (up to 2.33), which has been adopted back (2.39) and backported to all glibc releases after that version (2.34-2.38), which includes the version in Jammy (2.35 [3]). * The method it changes to is also exercised in other code paths (not just malloc()), thus it is already used and tested in Jammy -- it is not something new. [Other Info] * For details and analysis of (no) required dependencies, see comments #1, #2, and #3. * Upstream bug report [1] * Build-tested in PPA with supported archs and only -security (ppa:mfo/lp2089789) [4], with successful build & test-suite results. [0] glibc 2.33: $ git log --oneline origin/release/2.33/master -- sysdeps/unix/sysv/linux/getsysstats.c | grep 'misc: Add __get_nprocs_sched' $ glibc 2.34: $ git log --oneline origin/release/2.34/master -- sysdeps/unix/sysv/linux/getsysstats.c | grep 'misc: Add __get_nprocs_sched' e870aac8974c misc: Add __get_nprocs_sched glibc 2.35: $ git log --oneline origin/release/2.35/master -- sysdeps/unix/sysv/linux/getsysstats.c | grep 'misc: Add __get_nprocs_sched' 11a02b035b46 misc: Add __get_nprocs_sched [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30945 [2] https://sourceware.org/git/?p=glibc.git;a=commit;h=472894d2cfee5751b44c0aaa71ed87df81c8e62e [3] https://sourceware.org/git/?p=glibc.git;a=commit;h=d47c5e4db7924bb10efe14b787c4bd868b604e48 [4] https://launchpad.net/~mfo/+archive/ubuntu/lp2089789 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2089789/+subscriptions -- Mailing list: https://launchpad.net/~debcrafters-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~debcrafters-packages More help : https://help.launchpad.net/ListHelp
