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: 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:07:37 -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>
On Wed, Feb 11, 2015 at 01:34:53PM +0000, Mel Gorman wrote:
> > This indicates to me that the problem might actually be significant
> > over-allocation beyond the size that's actually going to be used. Do
> > we have some real-world specific examples of where this is happening?
>
> In the case of ebizzy, it is the case that do_stuff is so small that the
> allocation/free cost dominates.
ebizzy is supposed to be a benchmark simulating typical workload,
right? If so, I think this specific test operation is a mistake, and I
think glibc should be cautious about optimizing for benchmarks that
don't reflect meaningful real-world usage.
> 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.
Rich