romenskiy2012/jemalloc
1
0
Fork 0
mirror of https://github.com/jemalloc/jemalloc.git synced 2026-04-14 22:51:50 +03:00
Code Issues Projects Releases Packages Wiki Activity

Remove validation for HPA ratios

Browse source 
Config validation was introduced at 3aae792b with main intention to fix
infinite purging loop, but it didn't actually fix the underlying
problem, just masked it. Later 47d69b4ea was merged to address the same
problem.

Options `hpa_dirty_mult` and `hpa_hugification_threshold` have different
application dimensions: `hpa_dirty_mult` applied to active memory on the
shard, but `hpa_hugification_threshold` is a threshold for single
pageslab (hugepage). It doesn't make much sense to sum them up together.

While it is true that too high value of `hpa_dirty_mult` and too low
value of `hpa_hugification_threshold` can lead to pathological
behaviour, it is true for other options as well. Poor configurations
might lead to suboptimal and sometimes completely unacceptable
behaviour and that's OK, that is exactly the reason why they are called
poor.

There are other mechanism exist to prevent extreme behaviour, when we
hugified and then immediately purged page, see
`hpa_hugify_blocked_by_ndirty` function, which exist to prevent exactly
this case.

Lastly, `hpa_dirty_mult + hpa_hugification_threshold >= 1` constraint is
too tight and prevents a lot of valid configurations.
This commit is contained in:
Dmitry Ilvokhin 2024-11-15 08:53:20 -08:00 • committed by stanjo74
parent 0ce13c6fb5
commit 3820e38dc1
5 changed files with 1 additions and 102 deletions
Download patch file Download diff file Expand all files Collapse all files

2
test/unit/hpa_background_thread.sh
View file

@ -1,4 +1,4 @@
#!/bin/sh
export MALLOC_CONF="hpa_dirty_mult:0.001,hpa_hugification_threshold_ratio:1.0,hpa_min_purge_interval_ms:50,hpa_sec_nshards:0"
export MALLOC_CONF="hpa_dirty_mult:0,hpa_min_purge_interval_ms:50,hpa_sec_nshards:0"

56
test/unit/hpa_validate_conf.c
View file

@ -1,56 +0,0 @@
#include "test/jemalloc_test.h"
static bool abort_called = false;
static void (*default_malloc_message)(void *, const char *);
static void
mock_invalid_conf_abort(void) {
abort_called = true;
}
static void
null_malloc_message(void *_1, const char* _2) {
}
TEST_BEGIN(test_hpa_validate_conf) {
test_skip_if(!hpa_supported());
void *ptr = malloc(4096);
/* Need to restore this here to see any possible assert messages */
malloc_message = default_malloc_message;
assert_true(abort_called,
"Should have aborted due to invalid values for hpa_dirty_mult and "
"hpa_hugification_threshold_ratio");
free(ptr);
}
TEST_END
/*
* We have to set `abort_conf:true` here and not via the `MALLOC_CONF`
* environment variable in the associated shell script for this test. This is
* because when testing on FreeBSD (where Jemalloc is the system allocator) in
* CI configs where HPA is not supported, setting `abort_conf:true` there would
* result in the system Jemalloc picking this up and aborting before we could
* ever even launch the test.
*/
const char *malloc_conf = "abort_conf:true";
int
main(void) {
/*
* OK, this is a sort of nasty hack. We don't want to add *another*
* config option for HPA (the intent is that it becomes available on
* more platforms over time, and we're trying to prune back config
* options generally. But we'll get initialization errors on other
* platforms if we set hpa:true in the MALLOC_CONF (even if we set
* abort_conf:false as well). So we reach into the internals and set
* them directly, but only if we know that we're actually going to do
* something nontrivial in the tests.
*/
if (hpa_supported()) {
default_malloc_message = malloc_message;
malloc_message = null_malloc_message;
opt_hpa = true;
invalid_conf_abort = mock_invalid_conf_abort;
}
return test_no_reentrancy(test_hpa_validate_conf);
}

3
test/unit/hpa_validate_conf.sh
View file

@ -1,3 +0,0 @@
#!/bin/sh
export MALLOC_CONF='tcache:false,hpa_dirty_mult:0.25,hpa_hugification_threshold_ratio:0.6'