This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING] [v9] malloc: Consistently apply trim_threshold to all heaps [BZ #17195]
- From: Mel Gorman <mgorman at suse dot de>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Ond??ej B?lka <neleai at seznam dot cz>, Mike Frysinger <vapier at gentoo dot org>, Julian Taylor <jtaylor dot debian at googlemail dot com>, Chris Metcalf <cmetcalf at ezchip dot com>, libc-alpha at sourceware dot org
- Date: Fri, 1 May 2015 11:05:46 +0100
- Subject: Re: [PING] [v9] malloc: Consistently apply trim_threshold to all heaps [BZ #17195]
- Authentication-results: sourceware.org; auth=none
- References: <20150306142934 dot GX3087 at suse dot de> <20150316161333 dot GA3087 at suse dot de> <55071DB5 dot 5010702 at redhat dot com> <20150324154645 dot GA20062 at suse dot de> <20150401170238 dot GC32115 at domone> <20150401225419 dot GB20397 at suse dot de> <2106100772 dot 11112686 dot 1427957233362 dot JavaMail dot zimbra at redhat dot com> <20150402071721 dot GF20397 at suse dot de> <5542E696 dot 2060402 at redhat dot com>
On Thu, Apr 30, 2015 at 10:36:06PM -0400, Carlos O'Donell wrote:
> On 04/02/2015 03:17 AM, Mel Gorman wrote:
> > On Thu, Apr 02, 2015 at 02:47:13AM -0400, Siddhesh Poyarekar wrote:
> >> ----- Original Message -----
> >>>>>>> Ping as it's been a while since anyone said anything on it. I note
> >>>>>>> it's
> >>>>>>> in patchwork (http://patchwork.sourceware.org/patch/5496/) but do not
> >>>>>>> know if that means anyone plans to look at it. Thanks.
> >>
> >> I've tested and pushed this patch now. In future please also run the glibc
> >> testsuite and mention in your submission what the results were.
> >>
> >
> > Thanks very much. FWIW, the test suite was run and there was no change in the
> > number of passes or failures. I'll put that in the changelog in the future.
>
> Siddhesh, Mel,
>
> Sorry, I disappeared for vacation and just got back,
Hope it was a good one!
> but I did test the
> patch against some real workloads, and wanted to propose a slight tweak
> to what we have checked in. I would appreciate your opinions on the
> change.
>
I'd be interested in hearing about which workload motivated this for future
reference. I'm not 100% happy with the ones I used (mostly artificial
microbenches or proprietary workloads). The research papers for malloc
either used poor workloads or the source was unavailable but I could have
missed something.
Also FWIW, my trim patch is still making its way into opensuse. It got held
up by a bug in another package that was using uninitialsed memory. In the
future if there is a problem that points the finger at this patch, it's
worth testing with MALLOC_CHECK_ to see if that "fixes" it by zeroing memory.
> In _int_free, and systrim we have similar patterns to finding a chunk
> and freeing it, but in _int_free the logic is slightly different and
> my suggestion harmonizes with it:
>
> malloc/malloc.c (_int_free):
>
> 4042 if (av == &main_arena) {
> 4043 #ifndef MORECORE_CANNOT_TRIM
> 4044 if ((unsigned long)(chunksize(av->top)) >=
> 4045 (unsigned long)(mp_.trim_threshold))
> 4046 systrim(mp_.top_pad, av);
> 4047 #endif
>
> The trimming in _int_free is *only* done if the top chunk is at least
> the size of the trim threshold.
>
> This is slightly different to what we are doing right now in heap_trim
> which is to check if the extra space is at least the trim size. It is more
> precise to say "trim if the top chunk is at least the trim threshold"
> and it still fixes the issue at hand.
>
> What do you think?
>
I cannot think of any problems this might cause and it's better to be
consistent.
--
Mel Gorman
SUSE Labs