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 v2] Add malloc micro benchmark


Ond?ej B­lka <neleai@seznam.cz> 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...


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