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] Simple malloc benchtest.


On Mon, Dec 23, 2013 at 10:50:34AM +0100, OndÅej BÃlka wrote:
> You cannot do that, you would repeat same mistake that plagued allocator
> research in seventies, allocation patterns are simply different than
> simulations and all that you would get from that measurement is is meaningles garbage,
> see following link:
> 
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.5185&rep=rep1&type=pdf

I don't think the conclusions of that paper are valid because their
measurements are tweaked to give the most optimistic number possible.
They do pretend to use a more pessimistic measurement as well, but its
higher numbers are simply ignored in their conclusion, stating that
they're 'misleading'.

Additionally, we still need to account for allocator overhead (which
that paper correctly ignores, given its scope), so I'm going to modify
my request to ask for a simple measurement (which could get refined
over time) of allocator overhead and fragmentation - a single number
should be sufficient for now, since differentiating between allocator
overhead and fragmentation is only useful when you're comparing
different allocators.

If you want to put out a more comprehensive measurement of
fragmentation (+ overhead) over time, I'd suggest looking at memory
used vs memory requested at specific intervals and simply plot them
into a graph.  Of course, the actual graph is out of scope for now,
but you could at least get a limited set of plot points that a graph
generator could use and print them out for now.

Siddhesh


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