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: Malloc improvements


Anton Blanchard <anton@au1.ibm.com> writes:
> One potential issue - I struggled to capture the entire run.
> Even after bumping the buffer a bunch, I only traced a fraction of the
> run:

You're not the first, and I have a patch I'm testing that changes that
to use a file-backed mmap with a sliding window instead of having to
guess the right limit.

> And the output file was almost 1GB. Having the intermediate ASCII output
> is nice though, so I'm not arguing for getting rid of it. After
> processing, the binary file size ended up at 30MB.

I have a trace here that's 360 Gb, which is 24 Gb after conversion.

Although I am switching to a binary raw file, with a separate utility
for converting it to ASCII.  The size and time considerations were
significant.

> I'm not sure if I am running the tools correctly (or if I need to add
> anything for ppc64 other than the rdtsc* functions), but trace_run
> spends most of its time in pthread mutexes on POWER8:

It would be interesting to rerun that with my new converter (in case the
old one is overly pessimistic about synchronizing), but in general,
every time a pointer passes "ownership" from one thread to another, the
simulator puts in a set of calls to synchronize the two threads (the
sync_w and sync_r commands in trace_run.c).  If you can come up with a
faster way of doing it, or a way to reduce the number of times it's
needed, I'm all ears, but I'm not that worried about it - the purpose of
the simulator is to capture the application's malloc/free pattern "good
enough" to benchmark the glibc calls in a way that "represents" the
application's needs.  In the future, we'll be able to make performance
changes to malloc's code with a good understanding of how it impacts a
wide range of applications.

So as long as the simulator runs faster than the application, and does
the glibc calls in approximately the right order, I'm OK with it being
not perfectly fast ;-)


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