ClickHouse/contrib/jemalloc-cmake/include_linux_x86_64/jemalloc
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
..
internal Fix jemalloc assertion due to non-monotonic CLOCK_MONOTONIC_COARSE 2024-07-14 08:21:13 +02:00