81–90 of 181 posts
Perhaps that's something Microsoft can borrow and improve upon.
Of course, this opens up other issues with how to aggregate multiple cores, what the benchmark for 'max' should be, etc.
Perhaps the more fundamental answer is that there's no single metric that can sum up the situation for all use cases, in which case displaying '100%' would be more useful for a typical consumer while exposing multiple detailed metrics would be more useful for system admins and power users.
Earlier quoted context omitted.
What problem would this cause to me as a user, though? It sounds fine to me.
At 5% load, you might think there's 95% capacity to spare, but really it's actually something closer to 65%.
But okay, so there's some discrepancy, whether 15% or 30%. Okay, so I might underestimate it, and... then what? What would actually go wrong?
I think what you're not realizing is that underestimating capacity is a very different situation from overestimating it (especially when we're talking about underestimating like 0.4 GHz vs. 4 GHz, as opposed to overestimating 2-3 GHz as 4 GHz). When I'm looking at CPU usages it's almost always to figure out who's overutilizing the CPU, not underutilizing it. If I underestimate utilization, then at worst, what happens is I launch a program that needs all cores for max throughput (say a video encoder?), and then get disappointed at its throughput being too small. This is so infrequent (if it happens at all for the average user) that the additional mental effort required to factor in the throttling is quite negligible, and the negative consequences are quite mild. Compare that to the case where I overestimate utilization: suddenly I semi-panic and try to kill the program using the most CPU, and boom, suddenly I'm at risk of losing a bunch of data. The difference is quite asymmetric.
A key problem with this proposal is that modern CPUs do not have a single definitive maximum frequency. You have the base frequency which is rarely relevant outside of synthetic workloads then you have a variety of turbo frequencies which interact in complex ways. AMD's latest CPUs don't even have clear upper bounds on their frequency scaling logic. It's a big black box and the results can vary depending on the workl…
By this proposal's logic, it would make total sense for processes on a boosting CPU core to report more than 100% cpu usage.
Another approach may be to take inspiration from the `cpu load` metric on *nix systems and go _above_ 100%. In this example, the CPU usage would be `200%`: The system would like to be doing twice as much as it's currently doing, but something's throttling it. Of course, this opens up other issues with how to aggregate multiple cores, what the benchmark for 'max' should be, etc. Perhaps the more fundamental answer is…
So seeing 200 load doesn't indicate to me that it's throttled, but that it's using the equivalent of two full cores. Or did I misunderstand?
A key problem with this proposal is that modern CPUs do not have a single definitive maximum frequency. You have the base frequency which is rarely relevant outside of synthetic workloads then you have a variety of turbo frequencies which interact in complex ways. AMD's latest CPUs don't even have clear upper bounds on their frequency scaling logic. It's a big black box and the results can vary depending on the workl…
By this proposal's logic, it would make total sense for processes on a boosting CPU core to report more than 100% cpu usage.
> The etiology of military power is from War Emergency Power (WEP) which in the WWII era was a higher than normal rating power (i.e. >100% rated power) setting on an aircraft engine. Such power settings were approved for short durations (typically 5 minutes or less) such as takeoff and battle maneuvers.
> The term was quickly shortened to military power.
Earlier quoted context omitted.
> The earliest implementations of HT worked by statically partitioning Do you mean SMT in general? I don't think hyperthreading specifically has ever done that, but if I'm wrong I'd love to know more. (And AMD's version falls under "newer desktop-class processors")
I meant Intel HT specifically, but I'm going off memory here, and having trouble finding details on those old parts. Agner Fog's current microarchitecture manual doesn't mention HT in its discussion of the P4, but it does include at least one mention of static partitioning of the decoded op queue in the Atom core. It also describes several instances where Intel's desktop cores used to devote specific resources to eac…