Limit maximum number of purged slabs with option

Option `experimental_hpa_max_purge_nhp` introduced for backward
compatibility reasons: to make it possible to have behaviour similar
to buggy `hpa_strict_min_purge_interval` implementation.

When `experimental_hpa_max_purge_nhp` is set to -1, there is no limit
to number of slabs we'll purge on each iteration. Otherwise, we'll purge
no more than `experimental_hpa_max_purge_nhp` hugepages (slabs). This in
turn means we might not purge enough dirty pages to satisfy
`hpa_dirty_mult` requirement.

Combination of `hpa_dirty_mult`, `experimental_hpa_max_purge_nhp` and
`hpa_strict_min_purge_interval` options allows us to have steady rate of
pages returned back to the system. This provides a strickier latency
guarantees as number of `madvise` calls is bounded (and hence number of
TLB shootdowns is limited) in exchange to weaker memory usage
guarantees.
This commit is contained in:
Dmitry Ilvokhin 2024-08-06 08:47:57 -07:00 committed by Qi Wang
parent 143f458188
commit aaa29003ab
7 changed files with 109 additions and 6 deletions

View file

@ -552,7 +552,22 @@ hpa_shard_maybe_do_deferred_work(tsdn_t *tsdn, hpa_shard_t *shard,
* too frequently.
*/
if (hpa_min_purge_interval_passed(tsdn, shard)) {
while (hpa_should_purge(tsdn, shard) && nops < max_ops) {
size_t max_purges = max_ops;
/*
* Limit number of hugepages (slabs) to purge.
* When experimental_max_purge_nhp option is used, there is no
* guarantee we'll always respect dirty_mult option. Option
* experimental_max_purge_nhp provides a way to configure same
* behaviour as was possible before, with buggy implementation
* of purging algorithm.
*/
ssize_t max_purge_nhp = shard->opts.experimental_max_purge_nhp;
if (max_purge_nhp != -1 &&
max_purges > (size_t)max_purge_nhp) {
max_purges = max_purge_nhp;
}
while (hpa_should_purge(tsdn, shard) && nops < max_purges) {
if (!hpa_try_purge(tsdn, shard)) {
/*
* It is fine if we couldn't purge as sometimes