This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [RFC] malloc: Reduce worst-case behaviour with madvise and refault overhead

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?

buf = malloc(large_size);
while (data_to_process)

Is it simply that the software frameworks themselves are
unable to do this directly?

I can understand your position. Ebizzy models the workload and
you use the workload model to improve performance by changing
the runtime to match the workload.

The problem I face as a maintainer is that you've added
complexity to malloc in the form of a decaying counter, and
I need a strong justification for that kind of added complexity.

For example, I see you're from SUSE, have you put this change
through testing in your distribution builds or releases?
What were the results? Under what *real* workloads did this
make a difference?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]