Faithful, performant tracking of committed memory and limit enforcement

先阅读 mi_os_decommit_ex、_mi_prim_decommit、_mi_prim_commit、mi_arena_purge 和 mi_arena_try_alloc_at 周围的 Linux 路径。检查提议的 needs_recommit 行为和 mi_register_rss_callbacks API，以及报告的 benchmark 结果。在开始实现之前，维护者就准确的 committed-memory 记账方式和成对的限制执行回调达成一致，即视为完成。

Problem statement: We want to use mimalloc for an analytical database on Linux. We deploy the database in Kubernetes pods with a memory limit. If the process requests more memory than this limit, Kubernetes kills it. We want to avoid those out-of-memory kills and instead gracefully recover inside our database server.

Potential solution: To avoid our process getting killed, we want to track the amount of memory held by the process and fail allocations before requesting more memory from the operating system when the process is close to its limit.

At a high level, we need:

1. mimalloc to provide an accurate measure of its OS-backed memory and
2. a way for the embedding application to keep that measure below a limit.

Towards those goals, we propose two independent changes:

1. a mode in which committed follows physical memory with performance being on par with stock mimalloc
2. and paired callbacks through which the application can reject increases and observe decreases.

We have an in-house prototype of those changes, described in more detail below. We are happy to contribute those changes upstream, but before opening PRs would appreciate your feedback on our design thoughts. We would also be interested in any existing alternatives, prior discussions, configuration knobs, etc. which we may have missed.

Keeping committed aligned with RSS

We would like to use mimalloc's committed-memory statistic to track our RSS.
We measured our database on TPC-DS SF1000 using mimalloc 3.4.1 with MIMALLOC_ARENA_EAGER_COMMIT=0.
In a normal release build, the mimalloc committed counter (green) behaves like a high-water mark instead of following the process RSS (black).

This happens because mi_os_decommit_ex subtracts from committed only when _mi_prim_decommit returns needs_recommit == true. In a normal Linux release build, _mi_prim_decommit releases the physical pages with madvise(MADV_DONTNEED) but returns needs_recommit == false. mi_arena_purge therefore retains the slices_committed bits, and a later allocation in mi_arena_try_alloc_at call _mi_os_reuse instead of _mi_os_commit_ex.

The existing Linux implementation sets needs_recommit to true when mimalloc is built with MI_SECURE > 2. We repeated the same benchmark and runtime configuration with mimalloc built using MI_SECURE=4 and MI_FREE_IS_CHECKED=1. In this build, committed closely tracks RSS.
In those builds, mimalloc's committed-memory statistic closely tracks RSS.

However, it comes at a high performance cost. _mi_prim_decommit calls mprotect(PROT_NONE), and _mi_prim_commit later calls mprotect(PROT_READ|PROT_WRITE). These calls update the protection attributes of the affected Linux virtual memory areas (VMAs) and the corresponding page-table entries on every purge and recommit cycle. The full sequential benchmark recorded about 2.3 million additional mprotect calls, and the peak VMA count increased from 16,472 to 49,781. In a separate targeted benchmark, this led to a median runtime increase from 284s to 292 seconds, by 8s, i.e. 2.7%.

We want mimalloc's committed-memory statistic to closely track RSS, but don't want to pay this performance penalty.
We therefore propose a configuration that provides faithful committed-memory accounting without the overhead of calling mprotect. Our prototype always sets needs_recommit to true but omits the mprotect calls.

Enforcing a limit on committed memory

The embedding application needs to enforce a limit against the same accounting. We propose paired callbacks around changes to committed. Our prototype adds mi_commit_callback_fun(size_t bytes, void* arg) and mi_decommit_callback_fun(size_t bytes, void* arg), registered together through mi_register_rss_callbacks.

Before every increase to committed, the commit callback atomically reserves the corresponding number of bytes. If it returns false, mimalloc abandons the attempted increase and reports the allocation as failed. After every decrease to committed, the decommit callback releases those bytes. Bracketing every change to committed this way allows the application to maintain a race-free atomic counter across allocator threads.