Bug 1746933 - glibc: Backport malloc tcache enhancements (swbz#24531)
Summary: glibc: Backport malloc tcache enhancements (swbz#24531)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.2
Assignee: Arjun Shankar
QA Contact: qe-baseos-tools-bugs
Oss Tikhomirova
URL:
Whiteboard:
Depends On:
Blocks: 1746918
TreeView+ depends on / blocked
 
Reported: 2019-08-29 14:22 UTC by Carlos O'Donell
Modified: 2020-04-28 16:50 UTC (History)
8 users (show)

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.
Clone Of:
Environment:
Last Closed: 2020-04-28 16:50:14 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:1828 None None None 2020-04-28 16:50:50 UTC

Internal Links: 1821533

Description Carlos O'Donell 2019-08-29 14:22:44 UTC
Track release/2.28/master.

Backport:

commit 5ad533e8e65092be962e414e0417112c65d154fb
Author: Wilco Dijkstra <wdijkstr@arm.com>
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.

Comment 1 Florian Weimer 2019-10-22 13:29:21 UTC
We should backport these commits as well:

commit 77dc0d8643aa99c92bf671352b0a8adde705896f
Author: Joseph Myers <joseph@codesourcery.com>
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@arm.com>
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@redhat.com>
    
            * 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.

Comment 2 Arjun Shankar 2019-10-30 10:49:24 UTC
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.

Comment 4 Sergey Kolosov 2020-03-26 23:21:32 UTC
Verified with stap, memory_tunable_tcache_count sets in 0..65535 range.

Comment 5 Oss Tikhomirova 2020-04-15 17:22:49 UTC
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).

Comment 6 DJ Delorie 2020-04-15 18:36:28 UTC
Yes, that's correct.

Comment 7 Oss Tikhomirova 2020-04-16 16:10:14 UTC
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.

Comment 9 errata-xmlrpc 2020-04-28 16:50:14 UTC
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


Note You need to log in before you can comment on or make changes to this bug.