Centos 7, 400x медленнее для System.nanoTime, чем windows

Question

Я видел и читал сообщения о том, почему System.nanoTime() медленнее в некоторых ОС, чем в других, однако я никогда не видел ничего, объясняющего разницу, которую я вижу сейчас. Используя JMH, я запускаю этот тест. (Примечание: он также использует System.nanoTime())

@Benchmark
public long systemNanoTime() {
    return System.nanoTime();
}

В Windows 10 это занимает ~25 нс.

На Centos 7, Linux 3.10 это измеряется как ~10293 нс.

Это на той же машине, Intel(R) Core(TM) i7-7820X CPU @ 3,60 ГГц

Есть ли возможность изменить способ, которым JDK получает системные часы?

---

РЕДАКТИРОВАТЬ: на основе ссылки, предоставленной Тодд, кажется, что TSC не доступен

# more /sys/devices/system/clocksource/clocksource0/*
::::::::::::::
/sys/devices/system/clocksource/clocksource0/available_clocksource
::::::::::::::
hpet acpi_pm 
::::::::::::::
/sys/devices/system/clocksource/clocksource0/current_clocksource
::::::::::::::
hpet

после выполнения

echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

Задержка улучшилась, но все еще остается слабой с задержкой 1816 нс.

Я попытался выяснить, можно ли добавить тактовый источник TSC в Centos, но пока не повезло.

---

РЕДАКТИРОВАТЬ: копать немного дальше

# dmesg | grep -i tsc
[    0.000000] tsc: Detected 3600.000 MHz processor
[    0.058602] TSC deadline timer enabled
[    0.065868] TSC synchronization [CPU#0 -> CPU#1]:
[    0.065870] Measured 679995254538 cycles TSC warp between CPUs, turning off TSC clock.
[    0.065874] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[  125.451480] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode

Answer 1

По предложению @apangin я проследовал на этой странице, добавив альтернативный репозиторий для centos с последней версией

http://elrepo.org/tiki/tiki-index.php

а затем следовал дальнейшим инструкциям здесь

https://www.tecmint.com/install-upgrade-kernel-ve rsion-in-centos-7/

после установки и перезагрузки

# $ dmesg | grep -i tsc
[    0.001000] tsc: Detected 3600.000 MHz processor
[    0.001000] [Firmware Bug]: TSC ADJUST: CPU0: -2100392876408 force to 0
[    0.046075] TSC deadline timer enabled
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU1: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU2: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU3: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU4: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU5: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU6: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU7: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU8: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU9: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU10: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU11: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU12: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU13: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU14: 0
[    0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU15: 0
[    1.337843] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6c1bafbc2ab, max_idle_ns: 881591058496 ns
[    2.353636] clocksource: Switched to clocksource tsc

предположить, что ядро ​​подстраивается под ошибку прошивки.

Запустив тест снова, я получаю среднюю задержку в 40 нс, используя System.nanoTime(), что в 260 раз лучше. Это также означает, что тесты, использующие эту меру, являются более значимыми.