From ae8c90ebd1bf340dbf6a65c73efea9829b2c22f4 Mon Sep 17 00:00:00 2001 From: RajeshKumar11 Date: Fri, 27 Feb 2026 15:43:09 +0530 Subject: [PATCH] deps: prefer cpuinfo_cur_freq over scaling_cur_freq in uv_cpu_info() On Linux, uv_cpu_info() reads the current CPU frequency for each core from /sys/devices/system/cpu/cpuN/cpufreq/scaling_cur_freq. On some modern AMD CPUs (EPYC, Ryzen 9000 series) running inside containers, reading scaling_cur_freq triggers an ACPI/SMM round-trip that can take ~20ms per core, making os.cpus() take 500-600ms on a 32-core system. The file cpuinfo_cur_freq exposes the same current frequency information but reads from a hardware-cached register, avoiding the costly ACPI round-trip. Prefer it when available and fall back to scaling_cur_freq for systems that do not expose cpuinfo_cur_freq. Fixes: https://github.com/nodejs/node/issues/61998 --- deps/uv/src/unix/linux.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/deps/uv/src/unix/linux.c b/deps/uv/src/unix/linux.c index ea3e2de0384b2c..8de7718b5568a9 100644 --- a/deps/uv/src/unix/linux.c +++ b/deps/uv/src/unix/linux.c @@ -1886,10 +1886,19 @@ int uv_cpu_info(uv_cpu_info_t** ci, int* count) { 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;