This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: replace ptmalloc2
- From: Eric Wong <normalperson at yhbt dot net>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: JÃrn Engel <joern at purestorage dot com>, Rich Felker <dalias at libc dot org>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 20 Oct 2014 19:07:56 +0000
- Subject: Re: RFC: replace ptmalloc2
- Authentication-results: sourceware.org; auth=none
- References: <20141010010743 dot GA15146 at Sligo dot logfs dot org> <20141010012530 dot GX23797 at brightrain dot aerifal dot cx> <20141010013302 dot GC15146 at Sligo dot logfs dot org> <20141010020229 dot GY23797 at brightrain dot aerifal dot cx> <20141014233254 dot GA1860 at Sligo dot logfs dot org> <20141015040031 dot GR32028 at brightrain dot aerifal dot cx> <20141015045238 dot GA4528 at Sligo dot logfs dot org> <CANu=DmgNQm4A0ChTky+c4iSBwDjb5uAmsHd3H7MynQPjL3vecA at mail dot gmail dot com> <20141017090340 dot GA12253 at dcvr dot yhbt dot net> <CANu=Dmg8e4AfH28Kq84utUqL4c=x57JN46g3N4Z-Z_NTZ3j6nw at mail dot gmail dot com>
Will Newton <will.newton@linaro.org> wrote:
> On 17 October 2014 10:03, Eric Wong <normalperson@yhbt.net> wrote:
> > * Ability to take advantage of THP, but not inflate memory usage.
> > This is important for folks who run many threads w/o overcommit.
> > I think software like MySQL with 10s-100s of threads on a handful of
> > CPUs is here to stay. Getting folks to remember knobs like
> > MALLOC_ARENA_MAX is annoying and tiring.
>
> Do you have an idea in mind how malloc could integrate with THP?
(my untested/unverified ideas)
There should probably be two levels of allocation:
1. for large requests to the OS (>= 2M for x86-64)
2. per-thread arenas taking memory from the global pool
So the goal would be to keep as many >= 2M contiguous chunks as possible
and avoid unmapping smaller chunks (or maybe any middle chunks) which
can generate holes.
Per-thread arenas should avoid mmap/munmap/sbrk syscalls directly,
because:
* they'd encounter mmap_sem contention in the kernel anyways
* they lose the ability (in dlmalloc 2.8, at least) to detect+merge
contiguous MAP_ANON segments from separate mmap calls.
dlmalloc (2.8 at least) tries to detect contiguous MAP_ANON segments
from separate mmap calls and merge them. This usually works well with
Linux (unless the underlying application is doing its own MAP_ANON).