[PATCH] Add random memcpy test
Carlos O'Donell
carlos@redhat.com
Wed Jun 8 19:13:00 GMT 2016
On 06/07/2016 08:31 AM, Siddhesh Poyarekar wrote:
> 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.
OK.
The only workloads we have right now are a 389-ds workload (ldap multi-client
single server) and some qemu virt workloads (fio). I'm trying to get my
hands on a FreeIPA workload, along with a gluster workload. I'm trying to
cover a few of the key pain points: disk, vm, idm etc.
We are working on getting more workloads, recording them, and then making
them available as stored data to replay in the workload simulator.
--
Cheers,
Carlos.
More information about the Libc-alpha
mailing list