This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2] Add malloc micro benchmark
- From: DJ Delorie <dj at redhat dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 28 Feb 2018 16:56:28 -0500
- Subject: Re: [PATCH v2] Add malloc micro benchmark
- Authentication-results: sourceware.org; auth=none
Ond?ej Blka <email@example.com> writes:
> First for small sizes allocation would be just popping element from
> thread local single linked list, or calling function to refill lists
> with enough elements when empty.
This is basically what tcache does. Although I tested a few ways of
pre-filling the cache, there's room for more research there beyond the
few algorithms I used. Some folks have been experimenting with "ideal"
values for tcache_count and tcache_max too.
> Finally for larger allocations I would use page-based logic as
> mmaping/remapping/unmapping is about only way to actually decrease
> memory footprint, I didn't try that much yet.
Note that mmap() itself is expensive (slow) and there may be a limit on
how many discrete mapped regions a kernel[*] can support.
[*] glibc is not limited to the Linux kernel, so beware...