This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead
- From: Rich Felker <dalias at libc dot org>
- To: Mel Gorman <mgorman at suse dot de>
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 11 Feb 2015 09:21:50 -0500
- Subject: Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead
- Authentication-results: sourceware.org; auth=none
- References: <20150209140608 dot GD2395 at suse dot de> <54D91E06 dot 7060603 at redhat dot com> <20150211132631 dot GU23507 at brightrain dot aerifal dot cx> <20150211133453 dot GA31102 at suse dot de> <20150211140737 dot GX23507 at brightrain dot aerifal dot cx> <20150211141926 dot GA3087 at suse dot de>
On Wed, Feb 11, 2015 at 02:19:26PM +0000, Mel Gorman wrote:
> > > In the cases where I've seen this happen
> > > on other workloads (firefix, evolution, mariadb during database init from
> > > system) the cost of the operations on the buffer dominated. The malloc/free
> > > cost was there but the performance difference is in the noise.
> > If it's not distinguishable from noise in actual usage cases, then I'm
> > skeptical that there's a need to fix this issue.
> I take that is a NAK for v1 of the patch. How about V2? It is expected
> that heap trims can be controlled with tuning parameters but right now,
> it's not possible to tune the trim threshold for per-thread heaps. V2 of
> the patch fixes that and at least is consistent behaviour.
I don't think I'm qualified to discuss specific code changes to
glibc's allocator. I'll leave this to others who know it better. I was
just weighing in on the high-level aspects of the proposed changes
which made sense to discuss without knowledge specific to glibc's