This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [v4] malloc: Consistently apply trim_threshold to all heaps [BZ #17195]


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.

-- 
Mel Gorman
SUSE Labs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]