[Bug malloc/17195] excessive heap trimming in threaded programs even when disabled with mallopt

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17195

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  e4bc326dbbf7328775fe7dd39de1178821363e0a (commit)
      from  58a3a98d8f3488b659318b1a1c6efc169a6f06bf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e4bc326dbbf7328775fe7dd39de1178821363e0a

commit e4bc326dbbf7328775fe7dd39de1178821363e0a
Author: Carlos O'Donell <carlos@systemhalted.org>
Date:   Wed Oct 7 22:21:36 2015 -0400

    malloc: Consistently apply trim_threshold to all heaps (Bug 17195)

    In the per-thread arenas we apply trim_threshold-based checks
    to the extra space between the pad and the top_area. This isn't
    quite accurate and instead we should be harmonizing with the way
    in which trim_treshold is applied everywhere else like sysrtim
    and _int_free. The trimming check should be based on the size of
    the top chunk and only the size of the top chunk. The following
    patch harmonizes the trimming and make it consistent for the main
    arena and thread arenas.

    In the old code a large padding request might have meant that
    trimming was not triggered. Now trimming is considered first based
    on the chunk, then the pad is subtracted, and the remainder trimmed.
    This is how all the other trimmings operate. I didn't measure the
    performance difference of this change because it corrects what I
    consider to be a behavioural anomaly. We'll need some profile driven
    optimization to make this code better, and even there Ondrej and
    others have better ideas on how to speedup malloc.

    Tested on x86_64 with no regressions. Already reviewed by Siddhesh
    Poyarekar and Mel Gorman here and discussed here:
    https://sourceware.org/ml/libc-alpha/2015-05/msg00002.html

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog      |    6 ++++++
 malloc/arena.c |   10 ++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.