java - nanoseconds - Centos 7, 400 veces más lento para System.nanoTime que windows

system java

Question

He visto y leído publicaciones sobre por qué System.nanoTime () es más lento en algunos sistemas operativos que en otros, sin embargo, nunca he visto nada que explique la diferencia que estoy viendo ahora. Usando JMH, estoy ejecutando este punto de referencia. (Nota: también usa System.nanoTime ())

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

En Windows 10, esto lleva ~ 25 ns.

En Centos 7, Linux 3.10 se mide tomando ~ 10293 ns.

Esto está en la misma máquina, CPU Intel (R) Core (TM) i7-7820X a 3.60GHz

¿Hay alguna opción para cambiar la forma en que el JDK obtiene el reloj del sistema?

EDITAR: Basado en el enlace provisto por Todd, parece que tsc no está disponible

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

después de realizar

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

La latencia mejoró, pero aún es pobre con una latencia de 1.816 ns.

He intentado averiguar si la fuente de reloj TSC se puede agregar a Centos, pero todavía no tengo suerte.

EDITAR: Excavar un poco más

# 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

Basado en la sugerencia de @ apangin, seguí esta página al agregar el repositorio alternativo para centos con la última versión

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

y luego siguió las instrucciones adicionales aquí

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

después de instalar y reiniciar

# $ 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

sugiriendo que el kernel se está ajustando por una falla de firmware.

Ejecutando la prueba nuevamente, obtengo una latencia promedio de 40 ns usando System.nanoTime (), que es una mejora de 260 veces. También significa que los puntos de referencia que usan esta medida son más significativos.