3 ms·

Interesting, but what is the use case for tracking which CPUs your programs are using?

by sp332 3y ago

HeWhoLurksLate 3y ago
not a silicon engineer or even in the same sphere, but here's my guess- feel free to correct me if I'm wrong: Like Arm's big.LITTLE cpu designs, the last few Intel CPU design generations have used heterogenous CPU cores- some more powerful designed for fast execution, and other less powerful ones designed for power efficiency and density. AMD also has heterogenous cores now, too- with it's X3D chips utilizing chiplets with both stacked cache and without. Unlike how it used to be on x86, where a reasonable approach was to just spread jobs out evenly across all cores, now which core things go to can have a huge impact on speed, with some games running better on the higher cache cores of an X3D chip while others do better with the higher frequencies of the normal ones. In the future, I believe this will help reshape the backbone of thread scheduling to make it more efficient and have a better understanding of the processor it's working with without necessarily needing a significant amount of engineering work per heterogenous CPU that comes out.
- rbanffy 3y ago
  > I believe this will help reshape the backbone of thread scheduling to make it more efficient and have a better understanding of the processor it's working with Indeed. Ideally the kernel would intelligently pull processes that have lots of cache misses towards cores with more cache and processes with fewer misses towards cores with higher clocks. And do that with any finite resource that's unevenly distributed across cores, such as vector units and whatever performance counters can inform the scheduler about.
kevincox 3y ago
It sounds like it could be very useful for performance debugging. Using 50% of available CPU is very different when 50% and 50% than 100% and 0% of each available CPU. It could also be helpful for debugging performance with heterogeneous CPUs such as SMT, NUMA or performance/efficiency cores.
- jeffbee 3y ago
  SMTs are not heterogenous. It's right there in the name.
  - kevincox 3y ago
    If you have 4 threads and 2 cores there is very likely going to be a noticeable difference between running both of your threads on the same physical core vs one thread on each of the two cores. (Of course it depends what is running on the other thread of each core). Sure, maybe heterogeneous isn't the right word, much like NUMA is often not heterogeneous. But these do make CPU placement matter.
    - jeffbee 3y ago
      There's a widespread mental model of SMT that is totally incorrect, that holds there is one "real" thread and another one that only gets to fill in the gaps with unused resources. In reality, there is no such bias.
      - kevincox 3y ago
        I haven't heard of that bias before. But even without that bias it still does affect performance how your threads are distributed across physical cores. This is why the kernel is aware of SMT threads and uses that knowledge to make the best scheduling decisions.
      - shitlord 3y ago
        If you have three threads running on two cores, will the thread on its own significantly outperform the others?
        jeffbee 3y ago
        I don't understand the question. A hardware core, thread, context, or whatever term you prefer can only run one software thread at a given time. The operating system can interrupt the processor and switch to a different piece of software, but this only gives the illusion of two threads running concurrently when looked at over long time scales. If you have three software threads A, B, C and two CPUs X and Y, and thread A runs on CPU X from T0 to T2, thread B runs on Y from T0 to T1, and C runs on Y from T1 to T2, then thread A made more progress than the others, all else equal.
eklitzke 3y ago
This is useful for numa systems (e.g. to track how much time you spend on each numa socket), note that the memcg controller already has numa support. For example, depending on what mempolicy you have configured you may want to know how much memory is allocated on each numa node and also where the processes are mostly running, because remote numa memory accesses are more expensive. This is also generally useful if you're using cpusets (even if you're not on a numa system) because you may have them configured in a way where some CPUs belong to multiple cpusets. You can already get per-cpu CPU usage information, but this could help you figure out why a particular CPU has more usage than another.

Interesting, but what is the use case for tracking which CPUs your programs are using?

by sp332 3y ago

Interesting, but what is the use case for tracking which CPUs your programs are using?

not a silicon engineer or even in the same sphere, but here's my guess- feel free to correct me if I'm wrong: Like Arm's big.LITTLE cpu designs, the last few Intel CPU design generations have used heterogenous CPU cores- some more powerful designed for fast execution, and other less powerful ones designed for power efficiency and density. AMD also has heterogenous cores now, too- with it's X3D chips utilizing chiplets with both stacked cache and without. Unlike how it used to be on x86, where a reasonable approach was to just spread jobs out evenly across all cores, now which core things go to can have a huge impact on speed, with some games running better on the higher cache cores of an X3D chip while others do better with the higher frequencies of the normal ones. In the future, I believe this will help reshape the backbone of thread scheduling to make it more efficient and have a better understanding of the processor it's working with without necessarily needing a significant amount of engineering work per heterogenous CPU that comes out.

rbanffy 3y ago
> I believe this will help reshape the backbone of thread scheduling to make it more efficient and have a better understanding of the processor it's working with Indeed. Ideally the kernel would intelligently pull processes that have lots of cache misses towards cores with more cache and processes with fewer misses towards cores with higher clocks. And do that with any finite resource that's unevenly distributed across cores, such as vector units and whatever performance counters can inform the scheduler about.

kevincox 3y ago

It sounds like it could be very useful for performance debugging. Using 50% of available CPU is very different when 50% and 50% than 100% and 0% of each available CPU. It could also be helpful for debugging performance with heterogeneous CPUs such as SMT, NUMA or performance/efficiency cores.

jeffbee 3y ago
SMTs are not heterogenous. It's right there in the name.
- kevincox 3y ago
  If you have 4 threads and 2 cores there is very likely going to be a noticeable difference between running both of your threads on the same physical core vs one thread on each of the two cores. (Of course it depends what is running on the other thread of each core). Sure, maybe heterogeneous isn't the right word, much like NUMA is often not heterogeneous. But these do make CPU placement matter.
  - jeffbee 3y ago
    There's a widespread mental model of SMT that is totally incorrect, that holds there is one "real" thread and another one that only gets to fill in the gaps with unused resources. In reality, there is no such bias.
    - kevincox 3y ago
      I haven't heard of that bias before. But even without that bias it still does affect performance how your threads are distributed across physical cores. This is why the kernel is aware of SMT threads and uses that knowledge to make the best scheduling decisions.
    - shitlord 3y ago
      If you have three threads running on two cores, will the thread on its own significantly outperform the others?
      - jeffbee 3y ago
        I don't understand the question. A hardware core, thread, context, or whatever term you prefer can only run one software thread at a given time. The operating system can interrupt the processor and switch to a different piece of software, but this only gives the illusion of two threads running concurrently when looked at over long time scales. If you have three software threads A, B, C and two CPUs X and Y, and thread A runs on CPU X from T0 to T2, thread B runs on Y from T0 to T1, and C runs on Y from T1 to T2, then thread A made more progress than the others, all else equal.

eklitzke 3y ago

This is useful for numa systems (e.g. to track how much time you spend on each numa socket), note that the memcg controller already has numa support. For example, depending on what mempolicy you have configured you may want to know how much memory is allocated on each numa node and also where the processes are mostly running, because remote numa memory accesses are more expensive. This is also generally useful if you're using cpusets (even if you're not on a numa system) because you may have them configured in a way where some CPUs belong to multiple cpusets. You can already get per-cpu CPU usage information, but this could help you figure out why a particular CPU has more usage than another.