This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: replace ptmalloc2
- From: Jörn Engel <joern at purestorage dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 9 Oct 2014 18:33:02 -0700
- Subject: Re: RFC: replace ptmalloc2
- Authentication-results: sourceware.org; auth=none
- References: <20141009215447 dot GD8583 at Sligo dot logfs dot org> <CAAHN_R0JDNQkx7oV0HS9Knv7nsPZiARLeFb4zpPa+rj7cNfECg at mail dot gmail dot com> <20141010010743 dot GA15146 at Sligo dot logfs dot org> <20141010012530 dot GX23797 at brightrain dot aerifal dot cx>
On Thu, Oct 09, 2014 at 09:25:30PM -0400, Rich Felker wrote:
>
> Commit charge is the way you account for memory usage on a system with
> virtual memory in order that you don't run out of physical backing to
> instantiate all virtual memory that gets allocated. In the default
> Linux configuration without strict commit accounting
> (vm.overcommit_memory==0), it's just part of a heuristic, but with
> overcommit disabled (vm.overcommit_memory==2), it puts a hard limit on
> the amount of memory you can allocate. Any writable (or
> previously-writable-and-modified) private mapping, or shared memory
> that's not backed by a file/device, contributes to commit charge.
Ok, that makes sense. Assuming one wanted to improve ptmalloc2, a
reasonable approach might be to keep the commit charge low up to a
point, then switch to making all allocated memory writeable.
Rationale is that you don't want many small processes to individually
have a high commit charge, but the additional commit charge for a large
process is a small ratio of overall size.
Jörn
--
The key to performance is elegance, not battalions of special cases.
-- Jon Bentley and Doug McIlroy