summaryrefslogtreecommitdiff
path: root/src/process
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2015-08-07 19:19:49 +0000
committerRich Felker <dalias@aerifal.cx>2015-08-07 19:19:49 +0000
commitc3761622e8168b0c6453637ac82e70b09af3e8e9 (patch)
tree90e92a2e312a3ad7389b53b402b1aef4b4fe1008 /src/process
parent3c43c0761e1725fd5f89a9c028cbf43250abb913 (diff)
downloadmusl-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