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

Why this is a good first issue

Performance issue with os.cpus() on AMD CPUs in containers requires investigation and potential optimization.

AI Summary

The issue reports slow performance of os.cpus().length on modern AMD CPUs within containers, with strace showing delays in reading CPU frequency files. The problem appears reproducible but requires specific hardware and environment. Related discussions suggest this might involve libuv changes.

Issue Description

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