This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Mel Gorman <mgorman at suse dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 11 Feb 2015 10:50:08 -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> <20150211142150 dot GY23507 at brightrain dot aerifal dot cx>
On 02/11/2015 09:21 AM, Rich Felker wrote:
> 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
> malloc internals.
I'm looking at this now.
Cheers,
Carlos.