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: Carlos O'Donell <carlos at redhat dot com>
- Cc: Mel Gorman <mgorman at suse dot de>, Rik van Riel <riel at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Konstantin Serebryany <kcc at google dot com>, Minchan Kim <minchan dot kim at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 11 Feb 2015 08:19:03 -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> <20150209224947 dot GA21275 at suse dot de> <54DA25D0 dot 3050501 at redhat dot com> <20150210165414 dot GF2395 at suse dot de> <54DA5599 dot 2070804 at redhat dot com>
On Tue, Feb 10, 2015 at 02:01:45PM -0500, Carlos O'Donell wrote:
> >> Thus, instead of adding more complex heuristics to glibc's malloc I think
> > Is it really that complex? It's a basic heuristic comparing two counters
> > that affects the alloc and free slow paths. The checks are neglible in
> > comparison to the necessary work if glibc calls into the kernel.
> It is complex. It's a time-based integral value that is going to
> complicate debugging, reproducers, and users will need to be educated
> as to how it works.
One way to express this idea is that the complexity is emergent. The
code itself is not complex, but the resulting behavior, which is the
result of a feedback process with internal state and input from the
entire sequence of allocation and deallocation operations, is very