업무 특성상 성능이 지속적으로 일정하게 유지되어야 하는 상황에서 CPU clock speed를 고정하려 하는 상황에 대한 이해
System Infomation:
DL380 Gen11(Intel Xeon 4416+2.00GHz, 128GB Memory(64GB x 2 qty))
- Workload Profile(Low Latency, HPC)
- HyperThreading: Disabled
OS: CPUidle driver/governor
RHEL7.9: CPUidle driver/governor: none/menu
RHEL9.6: CPUidle driver/governor: acpi_idle/menu
OS boot kernel parameter 지정: cmdline- intel_idle.max_cstate=0 processor.max_cstate=1
동일한 HW - DL380 Gen11에서 OS를 RHEL 7.9 와 RHEL9.6을 이용하여 CPU clock speed를 모니터링 시도 하는 경우,
RHEL 7.9는 2.0 clock이 지속 표시되나, RHEL 9.6은 clock이 편차를 보이는 것이 확인됨
$ rg --no-heading -H -N MHz -g cpuinfo|sort|uniq -c
20 RHEL7.9/sosreport-hostname-2026-09-16-mqaqtlj/proc/cpuinfo:cpu MHz : 2000.000
1 RHEL9.6/sosreport-hostname-2026-09-14-rtkthqf/proc/cpuinfo:cpu MHz : 1991.228
1 RHEL9.6/sosreport-hostname-2026-09-14-rtkthqf/proc/cpuinfo:cpu MHz : 1992.424
1 RHEL9.6/sosreport-hostname-2026-09-14-rtkthqf/proc/cpuinfo:cpu MHz : 1997.241
15 RHEL9.6/sosreport-hostname-2026-09-14-rtkthqf/proc/cpuinfo:cpu MHz : 2000.000
1 RHEL9.6/sosreport-hostname-2026-09-14-rtkthqf/proc/cpuinfo:cpu MHz : 2000.020
1 RHEL9.6/sosreport-hostname-2026-09-14-rtkthqf/proc/cpuinfo:cpu MHz : 2004.237
기존 RHEL7.x 환경에서 CPU clock이 일정하게 표시되는 것은, OS Kernel에서 실제 CPU frequency를 반영하지 않고, BIOS/ACPI 테이블에서 넘겨받은 정적 표기용 클럭(Static Nominal Frequency)을 표시하기 때문이고,
신규 RHEL9.x환경의 경우, CPU의 하드웨어 카운터(MSR/Model-Specific Register,
MSR_IA32_APERF / MSR_IA32_MPERF)의 정보를 바탕으로 측정 시점의 CPU frequency를 열람/표시하기 때문
- System board의 수정 진동자(Crystal Oscillator)의 기준 클럭(Base Clock/BCLK)가 완벽하게 100.00MHz를 유지하지 못하고 99.98MHz ~ 100.02MHz 사이를 미세하게 변동하며 미세오차가 발생하게 되는데, CPU 동작 clock을 맞추기 위해 clock 조정(Multiplier)하는 과정에 오차가 크게 표시됨
참조예시 – Clock:
| 3.2GHz CPU: 100MHz (BCLK) × 32 (배수) = 3,200MHz (3.2GHz) 2.0GHz CPU: 100MHz (BCLK) × 20 (배수) = 2,000MHz (2.0GHz) |
| 99.995MHz (BCLK) × 20 (배수) = 1999.9MHz 100.005MHz (BCLK) × 20 (배수) = 2000.1MHz 98.520MHz (BCLK) × 20 (배수) = 1970.4MHz |
- MSR APERF/MPERF 카운터는 일정 시간 간격 동안 CPU가 수행한 실제 클럭 수를 카운트하여 계산되며, 커널이 이 값을 참조하는 시점의 미세한 시간 차이(샘플링 오차)로 인해 소수점 단위의 클럭 차이 또한 발생할 수(영향을 줄 수) 있음
Clock speed를 모니터링 하는 경우, turbostat이 권장됨.
OS에서 TSC_MHz가 일정하게 유지되고 있음에 따라 시스템 운용에 특이사항이 없음
측정되는 순간의 Jitter(오편차, 1999.9 MHz, 1970.4 MHz처럼 CPU별 MHz가 조금씩 다른 것)는 Application timestamp의 정확도 문제와 연관되지 않음 (실제 영향도 없음)
Linux 환경에서 Application은 OS로부터 시간을 얻게 되는데, OS는 CPU Frequency가 아닌 TSC(Time Stamp Counter, 일반적인 Linux Kernel의 기본적인 시간축 제공 역할)를 clocksource로 참조/이용해서 시간을 측정하게 됨
현대(Modern) x86 CPU의 invariant/constant TSC가 사용되는 경우, CPU operating frequency가 변화하더라도 TSC는 별도의 일정한 rate로 측정/진행함. Linux kernel역시 TSC의 안정성을 검사하고, 안정적인 TSC를 clocksource로 사용하게 됨
RHEL 문서에서도 TSC를 preferred clock source로 설명함
관련참조문서:
Optimizing RHEL 9 for Real Time for low latency operation
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/9/html/optimizing_rhel_9_for_real_time_for_low_latency_operation/managing-system-clocks-to-satisfy-application-needs_optimizing-rhel9-for-real-time-for-low-latency-operation?utm_source=gemini
Chapter 18. Managing system clocks to satisfy application needs
18.1. Hardware clocks
The preferred clock source is the Time Stamp Counter (TSC).