diff options
author | Carlos O'Donell <carlos@systemhalted.org> | 2015-10-07 22:21:36 -0400 |
---|---|---|
committer | Carlos O'Donell <carlos@systemhalted.org> | 2015-10-07 22:21:36 -0400 |
commit | e4bc326dbbf7328775fe7dd39de1178821363e0a (patch) | |
tree | 0574e1b889b71e501804b823857803348d282fc0 /mach/msg.c | |
parent | 58a3a98d8f3488b659318b1a1c6efc169a6f06bf (diff) | |
download | glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.tar glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.tar.gz glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.tar.bz2 glibc-e4bc326dbbf7328775fe7dd39de1178821363e0a.zip |
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
Diffstat (limited to 'mach/msg.c')
0 files changed, 0 insertions, 0 deletions