mirror of
https://github.com/jemalloc/jemalloc.git
synced 2026-04-28 05:42:17 +03:00
No description
b64d7815b7
Hugepages are really hard to get. Currently, we are waiting until we fill memory region up with data to at least `hpa_hugification_threshold` and then wait for `hpa_hugify_delay_ms` before we hugify pageslab. For this reason it seems wasteful to treat hugified pageslabs in the same way as non-hugified ones. Based on that observation two ideas come to mind. We should try to prioritize placing allocation on hugified pageslab to get performance improvements from hugepage usage immediately. While there are maybe a better (in terms of fragmentation) pageslab currently available, empty space on a hugepage just sitting there, waiting for a better allocation to appear, which might never happen. This unused memory on a hugepage is counted towards out usage anyway, we better use it for good. Same reasoning is applicable for purging prioritization. If we purge hugepage (`madvise(..., MADV_DONTNEED)`) we'll need to start over again to assemble it back: filling it up and waiting. Moreover, we might never assemble hugepage again, because kernel doesn't have continuous 2 MiB regions anymore. Instead, we should purge non-huge pageslabs as long as we can, because they are much cheaper to purge and does not provide any performance benefits. |
||
|---|---|---|
| .github/workflows | ||
| bin | ||
| build-aux | ||
| doc | ||
| doc_internal | ||
| include | ||
| m4 | ||
| msvc | ||
| scripts | ||
| src | ||
| test | ||
| .appveyor.yml | ||
| .autom4te.cfg | ||
| .cirrus.yml | ||
| .clang-format | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| autogen.sh | ||
| ChangeLog | ||
| config.stamp.in | ||
| configure.ac | ||
| COPYING | ||
| INSTALL.md | ||
| jemalloc.pc.in | ||
| Makefile.in | ||
| README | ||
| run_tests.sh | ||
| TUNING.md | ||
jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support. jemalloc first came into use as the FreeBSD libc allocator in 2005, and since then it has found its way into numerous applications that rely on its predictable behavior. In 2010 jemalloc development efforts broadened to include developer support features such as heap profiling and extensive monitoring/tuning hooks. Modern jemalloc releases continue to be integrated back into FreeBSD, and therefore versatility remains critical. Ongoing development efforts trend toward making jemalloc among the best allocators for a broad range of demanding applications, and eliminating/mitigating weaknesses that have practical repercussions for real world applications. The COPYING file contains copyright and licensing information. The INSTALL file contains information on how to configure, build, and install jemalloc. The ChangeLog file contains a brief summary of changes for each release. URL: https://jemalloc.net/