[HN Gopher] What should the CPU usage be of a fully-loaded CPU t...
___________________________________________________________________
What should the CPU usage be of a fully-loaded CPU that has been
throttled?
Author : pathompong
Score : 31 points
Date : 2021-07-03 22:01 UTC (58 minutes ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| jMyles wrote:
| I agree with the author. His thesis:
|
| > While I sympathize with this point of view, I feel that
| reporting the CPU usage at 50% is a more accurate representation
| of the situation.
| toxik wrote:
| Maldebrot set? Just look the word up my dude.
| boulos wrote:
| As long as we're being pedantic, Mandelbrot is a name.
| sgerenser wrote:
| I assume it was just a typo.
| mercora wrote:
| > Another theory is that this should report 50% CPU usage,
| because even though that CPU-intensive program is causing the CPU
| to consume all of its available cycles, it is not consuming all
| off the cycles that are potentially available.
|
| if they would be available wouldnt the CPU scaling kickin and
| ramp up the frequency as required? i think in this case it should
| really show up as 50%...
|
| otherwise its somewhat similar to battery charge status...
| apparently nobody wants to know what percentage of the initial
| full capacity is left but just how much is left from what is
| potentially available... so in a low power state were throttling
| is done permanently at some frequency i would just like to know
| how much capacity is actually left...
| buran77 wrote:
| The CPU may not be able to scale up the frequency to "100%" at
| that time due to factors that cannot be overridden, like a
| high-temp situation.
|
| The problem is what is 100% when CPUs have gotten so complex
| around the frequency. What's the absolute reference, the base
| frequency, the single core turbo, the multi core turbo,
| overclock, AVX?
|
| For batteries you usually get 2 estimates, a capacity
| percentage of the total practically possible, and one for how
| much usage you can get out of that based on recent or estimated
| usage.
| SavantIdiot wrote:
| This is precisely why most server farms turn off throttling: they
| need 100% predictable CPU utilization. I worked on power control
| strategies at Intel for quite some time, and we would often joke
| in server (Xeon) parts that it was pointless because all of our
| work was disabled.
|
| Early throttles were 50% duty cycles, then L1 bubble injections,
| then V/F frequency scaling. The author only addresses the early
| mechanisms, but it gets even more complex with the PCUs in the
| later Xeons.
| wonnage wrote:
| I think Apple's approach of attributing the capacity not
| available due to throttling (or various other reasons) to
| kernel_task might be the best. You can tell _something_ is eating
| cpu, stuff isn 't just stuck at 50% while the rest of the system
| looks idle.
|
| Although then you have users trying to figure out how to kill
| kernel_task, which isn't great either...
| bombcar wrote:
| Yeah until I learned how to see the throttling with "pmset -g
| thermlog" I didn't realize I was throttling so much.
|
| I feel that should be made clear on the various CPU usage
| utilities.
| kuschku wrote:
| That's actually an awesome idea, just create a virtual
| "cpu_throttling" task and attribute the throttling to this
| task.
| gervu wrote:
| Users trying to kill kernel_task sounds like an uncaught design
| problem. Replace the kill options in context drop-downs with
| "Why can't I kill kernel_task?" and have it pop open a short
| explanation, do the same as a feedback message if anyone tries
| to kill in the terminal.
|
| If the system doesn't do that already, either nobody considered
| that users would try that particular nonsensical thing, or
| nobody cared enough to let users find out immediately instead
| of wasting their time thinking the computer was at fault.
| eevilspock wrote:
| Maybe ditch relative (50%) for absolute (Hz)?
|
| That's what we do for other things that have no fixed upper
| bound, e.g. disk/network i/o. We even do this for memory now
| given dynamic virtual memory, etc.
| spullara wrote:
| Related, 50% CPU usage on a hyper-threaded CPU isn't 50%. It is
| usually closer to 80-90% depending on the workload. Something to
| watch out for when monitoring.
| undfg wrote:
| Interesting. Does this mean that if you are not going to use
| all HT threads it's better to turn off HT?
| wtallis wrote:
| Depends on the machine. The earliest implementations of HT
| worked by statically partitioning various caches and other
| resources in the processor core in half, which meant that a
| single-threaded process really could slow down by having HT
| enabled but not actively used. Newer desktop-class processors
| tend to have no significant downsides to leaving HT enabled,
| but there might still be some SMT implementations on niche
| products that don't handle this well.
| Dylan16807 wrote:
| No, don't turn it off. One thread on a core will go full
| speed, and two threads on a core will do more work than one
| thread. It's just that your utilization graph will be
| misleading. A naive graph will assume that two threads do
| twice as much work as one, but the real improvement is much
| smaller.
|
| If you turn off hyperthreading and keep the same exact
| workload, then instead of "the graph says 50% but it's really
| more like 80-90%", you'll have "the graph says 100% and it's
| correct". The numbers now accurately represent your lower
| capacity.
| wtallis wrote:
| When the OS has asked the CPU to slow down to more closely match
| the performance currently required by the software, then it is
| somewhat misleading to report that an application is using 90+%
| of the CPU time, even if the CPU is actually spending 90+% of its
| time running that application.
|
| However, when the CPU's speed has been reduced because it's too
| hot or the system is otherwise unable to allow the processor to
| sustain its full clock speed, you absolutely _should_ see the
| Task Manager reporting 100% utilization. This scenario is what
| more often comes to mind when the term "throttled" is used.
|
| If a hardware platform's power management capabilities make it
| impractical for the operating system to satisfy both of the above
| goals, then it should favor the latter goal, and err on the side
| of not lying to the user when your system is truly operating at
| its limits.
| magila wrote:
| 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 workload, temperature,
| silicon quality, phase of moon, etc.
| awesomeusername wrote:
| The OS can keep a record over time of the maximum frequency
| each CPU core has ever hit.
|
| This will take into account machine to machine variance, and
| even environmental factors effecting maximum speed.
| jeffbee wrote:
| Estimating x86 core frequency is a lot trickier than you've
| implied.
| toast0 wrote:
| Oh, but it gets more fun. The same operation can take more
| clocks for various reasons... If I really undervolt my Ryzen
| 2 apu, power usage and benchmarks go way down, but clock
| frequency stays high; the CPU is clock stretching and it gets
| a lot less work done.
|
| Anyway, current processors run a separate clock per core, and
| maximum clocks are only available when a small number of
| cores are active; if all cores are busy, that should really
| be 100%, even if each core is only doing 80% of max for a
| single core.
|
| Mostly, I want to see % of time cpu is busy, and separately,
| stats on how throttled the cpu is, because it's hard to
| combine both into a coherent number.
| wtallis wrote:
| That strategy guarantees that a process that runs for
| multiple minutes while consuming all available CPU cycles
| will be reported as using 100% CPU at most during the first
| few seconds, after which it will usually be reported as using
| somewhere less than 90%, and realistically could be reported
| as low as 65%. How is this helpful?
| tedunangst wrote:
| What if my program has a large working set and the CPU spends 50%
| of its cycles waiting for memory fetches to complete? What is its
| CPU usage?
| annoyingnoob wrote:
| I think we can have more nuance than a choice of 50% or 100%. I
| fall in the 'Show 100%' camp for sure, showing 50% but not
| indicating why isn't particularly helpful without knowing the
| background here. I think a separate indicator for an overall
| throttling condition would be helpful. Show a 100% usage and a
| throttle indicator together.
| buran77 wrote:
| Determining how much is in use out of what is practically
| available is relatively easy. But determining what is 100% is
| still difficult to decide on, CPUs have too many frequency
| options to decide what the "real" 100% point is. Even picking
| the base frequency as the reference would be a pain to properly
| monitor and predict, and to take decisions based on that.
| annoyingnoob wrote:
| Its more about determining what throttling means, 100% for
| conditions. In any case, the tools we are used to using have
| traditionally showed a percentage scale of usage - seems like
| a reasonable measure even if its hard to measure.
| woofie11 wrote:
| It's the testing problem: Trying to report squish too many
| numbers into one.
|
| The right reporting is to report both the numerator and the
| denominator. I'm using 800 MIPS out of 1200 MIPS available.
| wmf wrote:
| Power saving and "throttling" (usually it's un-turboing) are
| different cases that shouldn't be conflated; in one case the
| processor could run faster but in the other it can't. Ultimately
| we may want different metrics depending on what they're going to
| be used for. If you calculate relative to base frequency you will
| get utilization over 100% which is going to confuse some people.
|
| Linux has done some work in this area with frequency-invariant
| utilization tracking: https://lwn.net/Articles/816388/
| jeffbee wrote:
| I don't like to speak about "throttling" because all modern CPUs
| are in a closed-loop control system where the capacity of one
| core-second varies. There is no question about whether your CPU
| is throttled. It is, always. That leads to all the uncertainty
| about the denominator. We know how many cycles passed while a
| certain thread had the CPU, but we don't have very good ways to
| estimate the number of cycles that were available. If you take
| the analysis one layer deeper, does a program that waits on main
| memory while chasing pointers randomly use 100% of the CPU, or
| does it waste 99% of it, since it's not using most of the
| execution resources? Such a program could be said to be using
| 100% CPU time, but it won't respond to higher CPU clock speeds.
| When waiting for loads it makes no difference if time passes at
| 4GHz or 400MHz.
|
| So anyway, it is complicated.
___________________________________________________________________
(page generated 2021-07-03 23:00 UTC)