Bug 1746933
| Summary: | glibc: Backport malloc tcache enhancements (swbz#24531) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Carlos O'Donell <codonell> |
| Component: | glibc | Assignee: | Arjun Shankar <ashankar> |
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs |
| Severity: | unspecified | Docs Contact: | Oss Tikhomirova <otikhomi> |
| Priority: | unspecified | ||
| Version: | 8.2 | CC: | ashankar, codonell, dj, fweimer, mnewsome, otikhomi, pfrankli, skolosov |
| Target Milestone: | rc | Keywords: | Patch |
| Target Release: | 8.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | glibc-2.28-78.el8 | Doc Type: | Enhancement |
| Doc Text: |
.The `glibc.malloc.tcache` tunable has been enhanced
The `glibc.malloc.tcache_count` tunable allows to set the maximum number of memory chunks of each size that can be stored in the per-thread cache (tcache). With this update, the upper limit of the `glibc.malloc.tcache_count` tunable has been increased from 127 to 65535.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-28 16:50:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1746918 | ||
We should backport these commits as well:
commit 77dc0d8643aa99c92bf671352b0a8adde705896f
Author: Joseph Myers <joseph>
Date: Mon Feb 4 23:46:58 2019 +0000
Fix assertion in malloc.c:tcache_get.
One of the warnings that appears with -Wextra is "ordered comparison
of pointer with integer zero" in malloc.c:tcache_get, for the
assertion:
assert (tcache->entries[tc_idx] > 0);
Indeed, a "> 0" comparison does not make sense for
tcache->entries[tc_idx], which is a pointer. My guess is that
tcache->counts[tc_idx] is what's intended here, and this patch changes
the assertion accordingly.
Tested for x86_64.
* malloc/malloc.c (tcache_get): Compare tcache->counts[tc_idx]
with 0, not tcache->entries[tc_idx].
commit 1f50f2ad854c84ead522bfc7331b46dbe6057d53
Author: Wilco Dijkstra <wdijkstr>
Date: Fri May 17 18:16:20 2019 +0100
Small tcache improvements
Change the tcache->counts[] entries to uint16_t - this removes
the limit set by char and allows a larger tcache. Remove a few
redundant asserts.
bench-malloc-thread with 4 threads is ~15% faster on Cortex-A72.
Reviewed-by: DJ Delorie <dj>
* malloc/malloc.c (MAX_TCACHE_COUNT): Increase to UINT16_MAX.
(tcache_put): Remove redundant assert.
(tcache_get): Remove redundant asserts.
(__libc_malloc): Check tcache count is not zero.
* manual/tunables.texi (glibc.malloc.tcache_count): Update maximum.
Working on this now. Including the commits Florian mentions, this backport will bring us up-to-date with tcache improvements since 2.28 release: $ git log --oneline glibc-2.28..HEAD malloc | grep tcache 1f50f2ad85 Small tcache improvements 5ad533e8e6 Fix tcache count maximum (BZ #24531) 77dc0d8643 Fix assertion in malloc.c:tcache_get. 7c9a7c6836 malloc: Add another test for tcache double free check. affec03b71 malloc: tcache: Validate tc_idx before checking for double-frees [BZ #23907] bcdaad21d4 malloc: tcache double free check The top three (newest) commits upstream will be backported via this bug. The bottom three are already in RHEL-8.2. Verified with stap, memory_tunable_tcache_count sets in 0..65535 range. Hi Arjun, I'm working on the RHEL 8.2 release notes. Will you please confirm that the text provided below is accurate? Thank you in advance. .The `glibc.malloc.tcache` tunable has been enhanced With this update, the `glibc.malloc.tcache_count` tunable has an upper limit of 65535. Previously, the upper limit was 127. The `glibc.malloc.tcache_count` tunable allows to set the maximum number of memory chunks of each size that can be stored in the per-thread cache (tcache). Yes, that's correct. Thank you, DJ, for a fast review. I saw your post on the Red Hat developer blog (Malloc Internals and You) but thought I took a lot of your time already. I'll direct my future malloc questions to you. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:1828 |
Track release/2.28/master. Backport: commit 5ad533e8e65092be962e414e0417112c65d154fb Author: Wilco Dijkstra <wdijkstr> Date: Fri May 10 16:38:21 2019 +0100 Fix tcache count maximum (BZ #24531) The tcache counts[] array is a char, which has a very small range and thus may overflow. When setting tcache_count tunable, there is no overflow check. However the tunable must not be larger than the maximum value of the tcache counts[] array, otherwise it can overflow when filling the tcache. [BZ #24531] * malloc/malloc.c (MAX_TCACHE_COUNT): New define. (do_set_tcache_count): Only update if count is small enough. * manual/tunables.texi (glibc.malloc.tcache_count): Document max value.