We can't use defines for having pause as there is no guarantee that the computer we run the program has the same CPU as the one where we compiled.

Any detection of cpu instructions and the usage of them has to be done runtime

monty, I do not understand your comment. We do not have any run-time check for the PAUSE instruction. It is unnecessary, because that instruction is defined as REPE NOP. As far as I understand, the REPE a.k.a. REPZ a.k.a. REP prefix is documented to be mostly no-op, except when followed by a specific instruction opcode. Both REPE (0xf3) and NOP (0x90) should exist since the dawn of the Intel 8086 microprocessor.

Long time ago, REPE RET was employed to work around a hardware bug in AMD CPUs. https://gcc.gnu.org/legacy-ml/gcc-patches/2003-05/msg02117.html

So, basically, HAVE_PAUSE_INSTRUCTION can be always enabled on the IA-32 and AMD64 ISA. The reason for any compile-time check in cmake is that it did take a while for the compiler and linker toolchains to implement the PAUSE alias for REPE NOP.

monty said that we could make the message output dependent on global_system_variables.log_warnings > 2 or similar.

Measurements on two Intel Cascade Lake based systems suggest that the PAUSE instruction latency was reverted from the Skylake microarchitecture’s roughly 120 clock cycles to pre-Skylake levels (about 12 clock cycles). To compensate for that, it seems that a larger value of my_cpu_relax_multiplier would be useful. I think that it would be best to address that as part of this bug fix.

For the record, Intel documentation claims the following:

I believe that before it makes sense to perform any tweaks to the timing measurement in my_cpu_init(), we must address MDEV-22871 and run extensive benchmarks. Then we can say better what the my_cpu_relax_multiplier should be.