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: Mel Gorman <mgorman at suse dot de>
- To: Julian Taylor <jtaylor dot debian at googlemail dot com>
- Cc: libc-alpha at sourceware dot org, 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 16:47:41 +0000
- 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> <54E492FC dot 6020500 at googlemail dot com> <20150218150959 dot GP3087 at suse dot de> <54E4B308 dot 5040608 at googlemail dot com>
On Wed, Feb 18, 2015 at 04:43:04PM +0100, Julian Taylor wrote:
> On 02/18/2015 04:09 PM, Mel Gorman wrote:
> > On Wed, Feb 18, 2015 at 02:26:20PM +0100, Julian Taylor wrote:
> >> On 02/18/2015 11:29 AM, Mel Gorman wrote:
> >> I recall something along these lines for the original reasoning why the
> >> trim was not applied to thread arenas.
> > Is there any chance you can remember keywords in the discussion? The
> > changelog is completely void of information. Worse, it would have been
> > harder to hit this problem originally because new areas were only created
> > when contention occurred. If there was strong motivation for the pagesz
> > value then it's possible that it no longer applies.
> it was probably BZ#11261 that I remembered, its about excessive virtual
> memory usage due to arenas.
> As they are now trimmed less aggressively are we making it worse?
By a small margin. Worst case TRIM_THRESHOLD * ARENA_MAX and only applies
for a task that hits the exact case and never mallocs again. As the number
of arenas is bound and small by default, I cannot see a case where there
would be excessive amounts of memory wastage. Wasting a lot of memory
would require the application to be tuned specifically to waste memory.
The test case in question shows no difference in behaviour that I could
see but it's not actually trying to target the trim threshold case.