This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [v4] malloc: Consistently apply trim_threshold to all heaps [BZ #17195]
- From: Julian Taylor <jtaylor dot debian at googlemail dot com>
- To: Mel Gorman <mgorman at suse dot de>, libc-alpha at sourceware dot org
- Cc: Carlos O'Donell <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Rik van Riel <riel at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Konstantin Serebryany <kcc at google dot com>, Minchan Kim <minchan dot kim at gmail dot com>
- Date: Wed, 18 Feb 2015 14:26:20 +0100
- Subject: Re: [PATCH] [v4] malloc: Consistently apply trim_threshold to all heaps [BZ #17195]
- Authentication-results: sourceware.org; auth=none
- References: <20150218102900 dot GF23372 at suse dot de>
On 02/18/2015 11:29 AM, Mel Gorman wrote:
> diff --git a/malloc/arena.c b/malloc/arena.c
> index 886defb074a2..a78d4835a825 100644
> --- a/malloc/arena.c
> +++ b/malloc/arena.c
> @@ -696,7 +696,7 @@ heap_trim (heap_info *heap, size_t pad)
> top_size = chunksize (top_chunk);
> extra = (top_size - pad - MINSIZE - 1) & ~(pagesz - 1);
> - if (extra < (long) pagesz)
> + if (extra < (long) mp_.trim_threshold)
> return 0;
> /* Try to shrink. */
I am not very familiar with how the allocator works, what now happens
with this change when you are creating lots of temporary threads that
allocate memory below the trim treshold?
As I understand it each thread has its own arena, as they are now not
trimmed as often anymore is that area memory lost when the thread ends?
I recall something along these lines for the original reasoning why the
trim was not applied to thread arenas.