From aacfd6bfba9a3091c93c6b0483e508d2be339012 Mon Sep 17 00:00:00 2001 From: RajeshKumar11 Date: Fri, 27 Feb 2026 21:55:00 +0530 Subject: [PATCH] linux: prefer cpuinfo_cur_freq over scaling_cur_freq in uv_cpu_info() Reading scaling_cur_freq for each CPU core triggers a slow ACPI/SMM round-trip on some modern AMD CPUs (EPYC, Ryzen 9000 series), especially inside Linux containers, where the latency regularly reaches ~20ms per core. On a 32-core system this makes a single uv_cpu_info() call take 500-600ms. cpuinfo_cur_freq reports the same current-frequency value but reads from a hardware-cached register, avoiding the ACPI round-trip entirely. Prefer it when available and fall back to scaling_cur_freq for systems that do not expose cpuinfo_cur_freq (e.g. non-x86 platforms or systems without the cpufreq driver loaded). Fixes: https://github.com/libuv/libuv/issues/4098 --- src/unix/linux.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/unix/linux.c b/src/unix/linux.c index e98f3811c..5f37a2ae2 100644 --- a/src/unix/linux.c +++ b/src/unix/linux.c @@ -1867,10 +1867,19 @@ nocpuinfo: continue; n++; + /* Prefer cpuinfo_cur_freq: it reads a hardware-cached value and avoids + * slow ACPI/SMM round-trips that scaling_cur_freq triggers on some AMD + * CPUs (especially inside containers), which can take ~20ms per core. + * Fall back to scaling_cur_freq when cpuinfo_cur_freq is not available. + */ snprintf(buf, sizeof(buf), - "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_cur_freq", cpu); - + "/sys/devices/system/cpu/cpu%u/cpufreq/cpuinfo_cur_freq", cpu); fp = uv__open_file(buf); + if (fp == NULL) { + snprintf(buf, sizeof(buf), + "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_cur_freq", cpu); + fp = uv__open_file(buf); + } if (fp == NULL) continue;