This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add random memcpy test
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, 'GNU C Library' <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Tue, 7 Jun 2016 18:01:48 +0530
- Subject: Re: [PATCH] Add random memcpy test
- Authentication-results: sourceware.org; auth=none
- References: <AM3PR08MB008887BC4347EEC2C2AD7C4A83720 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com> <AM3PR08MB008830D95F894A1F1D334B57834A0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com> <DB3PR08MB0089596570EFB077FB73B79783590 at DB3PR08MB0089 dot eurprd08 dot prod dot outlook dot com> <20160603130914 dot GA28827 at devel dot intra dot reserved-bit dot com> <5751BA5F dot 4080800 at redhat dot com>
On Fri, Jun 03, 2016 at 01:11:59PM -0400, Carlos O'Donell wrote:
> - Trace malloc with minimal overhead during an application run.
> - Save traces of stored data.
> - Re-run trace in model simulator.
> - Allows you to play locally with malloc changes and see
> how they impact the saved workload.
>
> The problem is that this scales very slowly API by API.
>
> The whole system benchmarking project idea was that we would
> take traces of the whole system and then feed that data back
> as a workload that glibc can be tuned against.
>
> We have scaled it back to 1 process from 1 system, and to
> 1 API from the whole library.
My understanding is that is what we agreed on last year at the
Cauldron. If the workload you have is relevant (e.g. libvirtd with a
guest running and doing a live migration of a 10GB VM) then it would
be a great idea to have that included in the microbenchmark. In
future then we could encourage similar workloads to build up in here
and then move forward from there.
Siddhesh