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: Ond??ej B?lka <neleai at seznam dot cz>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, 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: Wed, 1 Apr 2015 23:55:31 +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>
On Wed, Apr 01, 2015 at 07:02:38PM +0200, Ond??ej B?lka wrote:
> On Tue, Mar 24, 2015 at 03:46:45PM +0000, Mel Gorman wrote:
> > On Mon, Mar 16, 2015 at 02:15:17PM -0400, Carlos O'Donell wrote:
> > > On 03/16/2015 12:13 PM, Mel Gorman wrote:
> > > > On Fri, Mar 06, 2015 at 02:29:34PM +0000, Mel Gorman wrote:
> > > >> Trimming heaps is a balance between saving memory and the system overhead
> > > >> required to update page tables and discard allocated pages. The malloc
> > > >> option M_TRIM_THRESHOLD is a tunable that users are meant to use to decide
> > > >> where this balance point is but it is only applied to the main arena.
> > > >>
> > > >
> > > > 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 actually have a build going with your patch and I'm trying to stress test
> > > it to see what impact it has on some real applications.
> > >
> >
> > Thanks. Any luck with this?
> >
> Is your testing finished?
>
Yes. The changelog already has details on the public benchmarks I used to
evaluate this.
> Also in my opinion M_TRIM_THRESHOLD looks like useless tunable. A better
> approach would be do trimming once per second to maximum in previous
> second. But that would be separate patch.
This is a separate entirely. Feel free to post a patch that removes
M_TRIM_THRESHOLD and replaces it with a per-second trigger that shrinks
heap based on historical usage.