From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30283 invoked by alias); 8 Oct 2015 02:23:55 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 30234 invoked by uid 55); 8 Oct 2015 02:23:50 -0000 From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug malloc/17195] excessive heap trimming in threaded programs even when disabled with mallopt Date: Thu, 08 Oct 2015 02:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Version: 2.19 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg00112.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17195 --- Comment #8 from 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 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.