8 ms·

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 per

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?)

deleted 3y ago
[deleted]
tootyskooty 3y ago
Sounds like power usage might fit the bill.
- zamadatix 3y ago
  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.
cduzz 3y ago
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?
- ahoka 3y ago
  Easy, measure the TDP usage instead of CPU usage, which is impossible to correctly measure at a given time anyway.
  - cduzz 3y ago
    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.
the8472 3y ago
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 https://docs.kernel.org/accounting/psi.html
- twoodfin 3y ago
  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.
  - Hello71 3y ago
    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.
paulddraper 3y ago
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.

deleted 3y ago

[deleted]

tootyskooty 3y ago

Sounds like power usage might fit the bill.

zamadatix 3y ago
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.

cduzz 3y ago

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?

ahoka 3y ago
Easy, measure the TDP usage instead of CPU usage, which is impossible to correctly measure at a given time anyway.
- cduzz 3y ago
  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.

the8472 3y ago

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 https://docs.kernel.org/accounting/psi.html

twoodfin 3y ago
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.
- Hello71 3y ago
  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.

paulddraper 3y ago

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.