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/time/localtime_r.c | |
parent | 3c43c0761e1725fd5f89a9c028cbf43250abb913 (diff) | |
download | musl-c3761622e8168b0c6453637ac82e70b09af3e8e9.tar.gz 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/time/localtime_r.c')
0 files changed, 0 insertions, 0 deletions