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 malloc micro benchmark


Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:

> +/* Benchmark the malloc/free performance of a varying number of blocks of a
> +   given size.  This enables performance tracking of the t-cache and fastbins.
> +   It tests 3 different scenarios: single-threaded using main arena,
> +   multi-threaded using thread-arena, and main arena with SINGLE_THREAD_P
> +   false.  */

Excellent!

>> I wonder if this could be done more elegantly, but I'm OK with a simple
>> approach for now.  If we end up adding many more such tests we might
>> need to revisit this part.
>
> The main concern was to get a clean state so that the test of a previous block
> size doesn't affect subsequent results.

Sorry, I meant a more efficient way to structure the Makefile, not the
test itself ;-)

>> How long does this test take to run, on average, compared to other
>> tests?  Do we have to worry about increasing timeouts for slow hosts?
>
> All the tests together runs finish in a fraction of the time taken by a single
> test of bench-malloc-thread, so if anything we need to reduce the time of
> that one by an order of magnitude (it takes ~5 minutes!).

Ok, thanks.

>> Simple loop, but doesn't test for malloc returning NULL.
>
> Yeah, the benchmark doesn't need to care since the amount we allocate
> is tiny (6.4MBytes).

I still think it's a good idea to check it, else we might end up with
artificially good results from free(NULL).


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