This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][malloc] Avoid atomics in have_fastchunks
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>, DJ Delorie <dj at redhat dot com>
- Cc: "carlos at redhat dot com" <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Wed, 20 Sep 2017 12:47:18 +0000
- Subject: Re: [PATCH][malloc] Avoid atomics in have_fastchunks
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- References: <DB6PR0801MB20532CCC6C45118D3C97589B83600@DB6PR0801MB2053.eurprd08.prod.outlook.com> <xnshfinzpy.fsf@greed.delorie.com>,<20170920065301.GA234@x4>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Markus Trippelsdorf wrote:
> The reason why nobody uses your trace/simulation patches is because they
> generate way too much data and are just too complex/invasive for most
> users. And someone would have to analyze all this data.
> So it is natural to look for other metrics like code complexity instead.
Indeed, I can generate hundreds of gigabytes of malloc traces in a few hours...
But what's the point? Traces are many orders of magnitude too large to share
(let alone commit), and unlike the workloads for the math functions it is difficult
to reduce a huge trace and yet remain 100% representative.
So I think we'll need to add microbenchmarks that test various aspects of
memory allocation. Extracting small representative kernels from existing
applications/benchmarks should be easier than dealing with huge traces...
Wilco