This is the mail archive of the libc-alpha@sourceware.org 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] Add random memcpy test


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.


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