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: Florian Weimer <fweimer at redhat dot com>
- Cc: Mel Gorman <mgorman at suse dot de>, libc-alpha at sourceware dot org
- Date: Tue, 10 Feb 2015 09:56:04 -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> <54D9F9E6 dot 6050606 at redhat dot com>
On 02/10/2015 07:30 AM, Florian Weimer wrote:
> On 02/09/2015 09:52 PM, Carlos O'Donell wrote:
>> On 02/09/2015 09:06 AM, Mel Gorman wrote:
>>> while (data_to_process) {
>>> buf = malloc(large_size);
>>> do_stuff();
>>> free(buf);
>>> }
>>
>> Why isn't the fix to change the application to hoist the
>> malloc out of the loop?
>
> For a lot of C++ code, this would require replacing global operator new
> with a pool allocator. We do not want programmers to do that, for
> various reasons (loss of tooling, our limited malloc hardening, etc.).
Is this because the objects are implicitly allocated by the language
in the inner loop using new?
Cheers,
Carlos.