This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] malloc per-thread cache ready for review
Carlos O'Donell wrote:
> On 02/02/2017 07:01 AM, Siddhesh Poyarekar wrote:
> > Can you share what kind of machines you ran your tests one?
A Cortex-A57 server.
> The next step would be to run with the high-speed API tracer turned on and
> provide a trace of the application workload to see what's going on.
I tried that using the instructions at https://sourceware.org/glibc/wiki/MallocTracing.
There are several issues, the preload binary reports errors when it is linked with other
GLIBCs (so you can't easily use it unless you've installed the malloc tracing GLIBC
as your system library somehow). Also it writes 64-byte records for every malloc/free,
so the trace files are absolutely huge, ~60GB for the one benchmark I tried.
It seems to me LEB128 compression of the address/size differences should make
it more reasonable - you could even remove the address if there is a count field in
each allocated block.
240,340 Kb Max RSS (43,372 -> 283,712)
208,070 Kb Max Ideal RSS
sizeof ticks_t is 8
Avg malloc time: 0 in 455,917,850 calls
Avg calloc time: 0 in 15 calls
Avg realloc time: 0 in 4 calls
Avg free time: 0 in 455,948,816 calls
Total call time: 0 cycles
Not sure now what we can do with these traces, since trace_run doesn't like being linked
with different GLIBCs, so I cannot use it to check the replay time of old vs new GLIBC malloc...
Wilco