diff options
author | Rich Felker <dalias@aerifal.cx> | 2022-09-28 08:33:05 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2022-10-19 14:01:31 -0400 |
commit | e6e8213244a816511e95e14fb99176442922abac (patch) | |
tree | ed212c679facb2a52855d3d6d423998f6870cb45 /src/thread/pthread_cond_timedwait.c | |
parent | 25e6fee27f4a293728dd15b659170e7b9c7db9bc (diff) | |
download | musl-e6e8213244a816511e95e14fb99176442922abac.tar.gz musl-e6e8213244a816511e95e14fb99176442922abac.tar.bz2 musl-e6e8213244a816511e95e14fb99176442922abac.tar.xz musl-e6e8213244a816511e95e14fb99176442922abac.zip |
disable MADV_FREE usage in mallocng
the entire intent of using madvise/MADV_FREE on freed slots is to
improve system performance by avoiding evicting cache of useful data,
or swapping useless data to disk, by marking any whole pages in the
freed slot as discardable by the kernel. in particular, unlike
unmapping the memory or replacing it with a PROT_NONE region, use of
MADV_FREE does not make any difference to memory accounting for commit
charge purposes, and so does not increase the memory available to
other processes in a non-overcommitted environment.
however, various measurements have shown that inordinate amounts of
time are spent performing madvise syscalls in processes which
frequently allocate and free medium sized objects in the size range
roughly between PAGESIZE and MMAP_THRESHOLD, to the point that the net
effect is almost surely significant performance degredation. so, turn
it off.
the code, which has some nontrivial logic for efficiently determining
whether there is a whole-page range to apply madvise to, is left in
place so that it can easily be re-enabled if desired, or later tuned
to only apply to certain sizes or to use additional heuristics.
Diffstat (limited to 'src/thread/pthread_cond_timedwait.c')
0 files changed, 0 insertions, 0 deletions