Azat Khuzhin 22611781b0 Fix jemalloc assertion due to non-monotonic CLOCK_MONOTONIC_COARSE ... Recently one tricky assertion of jemalloc had been discovered [1]: Failed assertion: "nstime_compare(&decay->epoch, new_time) <= 0" [1]: https://github.com/ClickHouse/ClickHouse/issues/66193 And as it turns out it is really possible for CLOCK_MONOTONIC_COARSE to go backwards, in a nutshell it can be done with ADJ_FREQUENCY, you can find example here [2]. And I can't trigger this issue for non-coarse clocks. [2]: https://gist.github.com/azat/7ea7f50ed75591b1af2d675a240ea94c?permalink_comment_id=5119222#gistcomment-5119222 But, jemalloc do not call clock_gettime() that frequently (I've verified it), so it can use non-coarse version - CLOCK_MONOTONIC I've also measured the latency of CLOCK_MONOTONIC and CLOCK_MONOTONIC_COARSE, and it is 20ns vs 4ns per call [3], so make this change affect performance you need really frequently calls of clock_gettime. [3]: https://gist.github.com/azat/622fa1f9a5d8e7d546ee9d294501961d?permalink_comment_id=5119245#gistcomment-5119245 Interesting, that this bug started to appears only after jemalloc heap profiler had been enabled by default [4], no clue why (I would believe more in a more frequent calls to clock_adjtime(ADJ_FREQUENCY), but I can't verify this) [4]: https://github.com/ClickHouse/ClickHouse/pull/65702 To be continued... Fixes: https://github.com/ClickHouse/ClickHouse/issues/66193 Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>		2024-07-14 08:21:13 +02:00
..
jemalloc/internal