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: RFC: replace ptmalloc2


On Thu, Oct 09, 2014 at 06:33:02PM -0700, JÃrn Engel wrote:
> 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.

The sane behavior is to keep the same PROT_NONE/mprotect pattern, but
expand by exponentially increasing amounts rather than one page each
time. E.g. force the Nth expansion to be at least 2^N pages.

Rich


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