Centos 7, 400x slower for System.nanoTime than windows

Question

我已经看到并阅读了关于为什么System.nanoTime((在某些操作系统上比其他操作系统慢的文章，但是我从未看到任何可以解释我现在看到的差异。使用 JMH，我正在运行此基准测试。(注意：它也使用System.nanoTime((

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

在 Windows 10 上，这需要 ~25 ns。

在 Centos 7，Linux 3.10 上，它被测量为 ~10293 ns。

这是在同一台机器上， 英特尔(R( 酷睿(TM( i7-7820X CPU @ 3.60GHz

是否有选项可以更改 JDK 获取系统时钟的方式？

---

编辑：根据Todd提供的链接，似乎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

延迟有所改善，但延迟仍然很差，延迟为 1,816 ns。

我试图找出 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-version-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

建议内核正在针对固件错误进行调整。

再次运行测试，我使用 System.nanoTime(( 的平均延迟为 40 ns，这是 260 倍的改进。 这也意味着使用这种衡量标准的基准更有意义。