diff options
author | Rich Felker <dalias@aerifal.cx> | 2015-08-07 19:19:49 +0000 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2015-08-07 19:19:49 +0000 |
commit | c3761622e8168b0c6453637ac82e70b09af3e8e9 (patch) | |
tree | 90e92a2e312a3ad7389b53b402b1aef4b4fe1008 /src/process | |
parent | 3c43c0761e1725fd5f89a9c028cbf43250abb913 (diff) | |
download | musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.tar.gz musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.tar.bz2 musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.tar.xz musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.zip |
mitigate blow-up of heap size under malloc/free contention
during calls to free, any free chunks adjacent to the chunk being
freed are momentarily held in allocated state for the purpose of
merging, possibly leaving little or no available free memory for other
threads to allocate. under this condition, other threads will attempt
to expand the heap rather than waiting to use memory that will soon be
available. the race window where this happens is normally very small,
but became huge when free chooses to use madvise to release unused
physical memory, causing unbounded heap size growth.
this patch drastically shrinks the race window for unwanted heap
expansion by performing madvise with the bin lock held and marking the
bin non-empty in the binmask before making the expensive madvise
syscall. testing by Timo Teräs has shown this approach to be a
suitable mitigation.
more invasive changes to the synchronization between malloc and free
would be needed to completely eliminate the problem. it's not clear
whether such changes would improve or worsen typical-case performance,
or whether this would be a worthwhile direction to take malloc
development.
Diffstat (limited to 'src/process')
0 files changed, 0 insertions, 0 deletions