This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Possible inline malloc alternatives: bitmap
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "eggert at cs dot ucla dot edu" <eggert at cs dot ucla dot edu>, Ondřej Bílka <neleai at seznam dot cz>
- Cc: nd <nd at arm dot com>, Carlos O'Donell <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Sun, 4 Mar 2018 14:07:08 +0000
- Subject: Re: Possible inline malloc alternatives: bitmap
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Paul Eggert wrote:
> You can freely read an older NightWatch paper here:
>
> Although NightWatch's source code is freely readable (it's on GitHub), it does not specify a software licence so I have not read it and don't recommend that you read it.
> > One problem is that it merges several different issues.
>
> Yes, a problem common to many systems papers.
Indeed, it is not relevant to the issues we are having with GLIBC malloc. The paper is about
system wide cache partitioning which is very system specific and between processes.
> I didn't quite follow your profiling proposals. As near as I can make out you'd like to log calls to malloc, free, etc. But for good results don't you also need to log memory accesses? Otherwise how will you know which objects are hot?
I don't believe it is feasible to profile malloc more accurately, but neither is it necessary
for a quick evaluation of malloc improvements like (de)allocation performance and
fragmentation reduction. You always need to run the original benchmark to prove the
gains are real.
Wilco