Hacker News Reader

Comment by bloopernova | Hacker News Reader

I want a better system load metric now that we've got heterogenous cores in CPUs. The Pixel 8 Pro has 3 types, efficiency, performance, and one single ultra performance core.

If your efficiency cores are always close to max usage, but your performance cores are idle, is your system being heavily or barely used?

I understand that system load isn't really a useful metric between systems, but it's useful to compare on a single system I think. I just want a better at-a-glance thing to communicate to me if my computer is under or overloaded.

(Additionally, do you have to specify that a particular app can run on efficiency cores, or does the process scheduler do it all without input from a human?)

View on HN

linux has pressure stall information[0] which tracks the time where some processes couldn't be run because they were waiting for contended resources (cpu/io/memory). An N-parallel compute-bound job on an M-thread CPU will stay at nearly 0 CPU pressure if N=M (assuming no background tasks) because they're not stepping on each other's toes. At N>M pressure will start to rise.

[0] https://docs.kernel.org/accounting/psi.html

Note that for memory, as I understand the documentation, it's less about "couldn't be run" than "couldn't have the real memory allocation necessary to avoid paging".

This is in contrast to another contended resource, memory bandwidth, "waiting" for which manifests at the process level as CPU cycles like any other code. It's possible to use profiling tools to distinguish memory waits from other CPU activity, but as far as I know nobody has built the infrastructure to bubble that data up in some form so it could be tracked systemically by the OS.

I can guess why: The memory hierarchy is complicated, and what you can derive about it from CPU performance counters is indirect and limited. Still, even some basic estimation for how many cache lines a process was responsible for driving over the memory bus would be helpful for those building high-performance systems and applications.

PSI is exported by the kernel to track context switches: switch to idle process = io wait, switch to kswapd = mem wait, switch to other runnable process = cpu wait. these are already visible to the kernel, it just needs to increment some counters and expose those to userspace. you can get the perf counters with something like `perf stat -ae cache-misses sleep 60`, it doesn't need to be in /proc.

additionally, context switches are the same on everything that can run Linux, whereas PMU counters are highly CPU-specific (potentially even different in each CPU stepping), so given the current state of affairs, a generic interface would be very limited.

Isn't this just a subset of the existing capacity monitoring problem where I want to know how loaded a multi-core system is under the following scenario:

Some critical path, single-threaded task is at 100% of capacity of a core; the system has 10 cores -- is my system at 10% utilization or 100% utilization?

Easy, measure the TDP usage instead of CPU usage, which is impossible to correctly measure at a given time anyway.

Well, I certainly track capacity by power used by servers under management, but a system that's pinned on one thread is at 100% utilization, for very real definitions of "capacity" but the power consumed will also be some small fraction of how much power would be drawn if you were lighting up all the cores at 100% also.

Sounds like power usage might fit the bill.

Raw power usage is very skewed. Getting that last 20% of performance the chip is capable of might take as much power as the first 80% did, and not each type of workload may have the same skew depending on which components are being stressed and how. Say you did have an adjusted map of power<->utilization though, it still assumes "system utilization" means "how much of the total possible capacity of this system is being utilized". This is a valid take, if you can get such a mapping, but it's not necessarily the only valid take of what system load is.

Huh? # of running processes is the usage of the system.

---

If your system is running it on CPU, GPUs, high-efficiency, low-efficiency, etc....that's the performance level of your system, not the load on your system.

This is nothing new. We've had power-saving CPU throttling for ages. Carry on.

Reply on news.ycombinator.com