Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What should the CPU usage be of a fully-loaded CPU that has been throttled?

devblogs.microsoft.com

Post reply on HN
Print view View original

31–40 of 181 posts

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#31

Post by Dylan16807 »

wtallis wrote: post #23
undfg wrote: post #14

Earlier quoted context omitted.

Interesting. Does this mean that if you are not going to use all HT threads it's better to turn off HT?

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…

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

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#32

Post by userbinator »

As far as I know, "CPU usage" of a process has always been "percentage of time spent in it" so I think anything else is overthinking/overcomplicating things. It makes perfect sense for CPU usage to go up if the frequency starts falling due to throttling. That's why a separate indication of current CPU frequency is necessary.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#33

Post by temac »

It only makes sense to report e.g. 50% in case of throttling if you also report e.g. 130% in case of boosting (on a single core).

Which could be useful.

Now throw HT in the mix and loose your mind.

I'm not sure there is a really better solution. Just document the one you choose, please!

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#34

Post by dataflow »

> half-speed for whatever reason

IMHO the reason actually does matter.

Utilization should be relative to the maximum frequency the CPU could be running the same instructions at. If the CPU is throttling to save power, then it could be running the same instructions at a higher frequency, so utilization should be relative to the higher one. If it's throttling to lower the temperature, then it can't be running the same instructions at a higher frequency, so it's already maxed out at 100%.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#35

Post by jrockway »

undfg wrote: post #14
spullara wrote: post #7

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.

Interesting. Does this mean that if you are not going to use all HT threads it's better to turn off HT?

SMT is usually a throughput win, and usually a latency loss. I was playing with my Threadripper a while back and for C++ builds of large projects, HT results in about a 10% improvement in compilation speed. 10% is a big deal and you should take it. The downside is that games had noticeably lower framerates even with the rest of the CPU idle (at least the games I play are bounded by single-thread performance across maybe 2-4 cores). I kind of blame Windows's scheduler there, since it should be able to say "hey, a game is running, don't schedule anything on the same physical core that has a game thread running on it", but I don't think it does. It might schedule both game thraeds on the same physical core and then they contend with each other and run 40% slower each. Also be careful about memory -- 64GB wasn't enough for 64 concurrent clang runs. You need a little bit more (but of course 128GB is the next installable increment). (I can also see more threads aggravating other resource constraints; notably disk IOPS, but I didn't notice a problem there myself. It's also possible that SMT increases power use and so decreases turbo speeds, and that might have an impact. I didn't measure that when I was testing.)

For me, I keep SMT turned off. The latency is more important than the throughput for my workstation, but if you do full builds of C++ regularly, you might want it on. Use the 10% time you're getting back to switch to a build system that can cache things, though.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#36

Post by temac »

wtallis wrote: post #23
undfg wrote: post #14

Earlier quoted context omitted.

Interesting. Does this mean that if you are not going to use all HT threads it's better to turn off HT?

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…

There still are (and probably will always be) some workloads where using HT makes the whole task take longer, but unless you only run that kind of loads, optimizing is simply a matter of e.g. loading up to core numbers instead of threads when you run those loads on modern CPUs.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#37

Post by formerly_proven »

"CPU usage" as in "how many time-slices did this process eat?" is pretty easy to understand and generally points at the right things ("What's eating all that CPU?", "Is this application using the correct number of threads?" etc.)

Trying to express "How much of the hypothetically available computational resources of the CPU did this application consume?" in a single number would seem like a futile exercise at best. VTune used to have something like this which IIRC was based on using all cores in parallel sections and IPC or something like that. It wasn't very meaningful, and is impacted by all sorts of factors.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#38

Post by dataflow »

userbinator wrote: post #32

As far as I know, "CPU usage" of a process has always been "percentage of time spent in it" so I think anything else is overthinking/overcomplicating things. It makes perfect sense for CPU usage to go up if the frequency starts falling due to throttling. That's why a separate indication of current CPU frequency is necessary.

I find this intuitive for thermal throttling, but not for power throttling, though I'm not sure changing the definition makes sense now (it might not even be practical). I've frequently fired up some process manager and seen it at > 50% CPU despite the system not running anything interesting, and it always takes me a second to realize that it's throttled down to like 400 MHz and the process manager itself is consuming what's left of the CPU.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#39

Post by jeffbee »

SavantIdiot wrote: post #26

This is precisely why all of the large volume cloud server farms I worked with 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 autho…

I have managed several extremely large fleets of computers and I can tell you they all use frequency scaling. I seriously doubt that your statement applies to "most server farms" when properly weighted.

Re: What should the CPU usage be of a fully-loaded CPU that has been throttled?

#40

Post by nightpool »

dataflow wrote: post #34

> half-speed for whatever reason IMHO the reason actually does matter. Utilization should be relative to the maximum frequency the CPU could be running the same instructions at. If the CPU is throttling to save power, then it could be running the same instructions at a higher frequency, so utilization should be relative to the higher one. If it's throttling to lower the temperature, then it can't be running the same…

that doesn't solve the "relative measures make the graph useless" problem though, does it?
Post reply on HN