public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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 [thread overview] Message-ID: <bug-17195-131-ON4fGbWmvh@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-17195-131@http.sourceware.org/bugzilla/> 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.
prev parent reply other threads:[~2015-10-08 2:23 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-24 11:04 [Bug malloc/17195] New: excessive heap trimming in threaded programs jtaylor.debian at googlemail dot com 2014-07-24 11:07 ` [Bug malloc/17195] excessive heap trimming in threaded programs even when disabled with mallopt jtaylor.debian at googlemail dot com 2014-08-30 12:34 ` neleai at seznam dot cz 2014-08-30 12:40 ` jtaylor.debian at googlemail dot com 2015-02-12 17:46 ` jtaylor.debian at googlemail dot com 2015-02-18 5:48 ` siddhesh at redhat dot com 2015-04-02 6:46 ` cvs-commit at gcc dot gnu.org 2015-04-02 6:48 ` siddhesh at redhat dot com 2015-10-08 2:23 ` cvs-commit at gcc dot gnu.org [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-17195-131-ON4fGbWmvh@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).