os.cpus().length performance on modern AMD CPUs inside containers

Version

v24.14.0

Platform

- Bare metal machine
- Host: Linux Ubuntu 24
- Container Image: `node:alpine-24`
- CPU: `AMD EPYC 4584PX 16-Core Processor`

Subsystem

os

What steps will reproduce the bug?

Firstly, I'm not entirely sure if this is a bug, so apologies if this is known or in the wrong spot - it just feels like something that shouldn't be this slow vs other platforms. I couldn't find any other real references to this other than a discussion at https://github.com/nodejs/performance/issues/93 which mentions this being slow.

With a modern AMD CPU such as the one listed above, run the following with Docker:

• docker run --rm node:24-alpine node -e "console.time('cpus'); os.cpus().length; console.timeEnd('cpus')"

I've also attached an strace output for reference. It seems to iterate over /sys/devices/system/cpu/cpuN/cpufreq/scaling_cur_freq, some of which can take 20ms to return.

strace.log

How often does it reproduce? Is there a required condition?

This requires a modern AMD CPU, with Linux, and run within a container. Otherwise it seems to happen almost 100% of the time in our testing.

What is the expected behavior? Why is that the expected behavior?

I would expect it to return much more quickly as it does on Intel systems.

What do you see instead?

cpus: 649.982ms
regularly >500ms runtime on a machine with 32 cores.

Additional information

No response

首先，在所列出的 AMD/Linux 设置上复现 issue 中的 Docker 命令，并检查附带的 strace.log。跟踪读取 scaling_cur_freq 的 os.cpus() 路径，然后将其行为与 Intel 系统进行比较；完成的标准是测量到的调用速度显著提升，同时不改变其结果。