On 06/09 07:06, Rich Freeman wrote: > On Tue, Jun 9, 2020 at 5:17 AM <[email protected]> wrote: > > > > What is the difference between 100% CPU load and 100% CPU load to > > create such an difference in temperature? > > How is X% load calculated? > > > > I think a lot more detail around what you're actually running would be > needed to provide more insight here. I can think of a few things that > could cause this: > > The kernel maintains a number of stats around CPU load including % > utilized by userspace, the kernel, IRQs, IO waiting, and truly idle > time. Depending on where you were getting that "100%" figure I can't > be sure what was included in that. If it was just 100-idle then you > could have had IO waiting included in the load - this is time when you > have a running process that wants to do something but it is blocked on > IO, such as reading from a disk. If you have 12 threads all doing > random IO from a spinning hard disk you can easily end up with the CPU > spending a whole lot of time doing nothing, but where it is otherwise > "busy." If the stat was system+user then that reflects actual CPU > processing activity. > > Next, not all instructions are created equally, and a CPU core is a > fairly complex device that has many subdivisions. There are circuits > that do nothing but integer or floating-point math, others that > fetch/store data, some that do logical comparisons, and so on. While > the OS tries to keep all the CPU cores busy, the CPU core itself also > tries to keep all of its components busy (something aided by > optimizing compilers). However, the CPU only has so many instructions > in the pipeline at one time, and they often have interdependencies, > and so the CPU can only use out-of-order execution to a limited degree > to keep all its parts active. If you get a lot of cache misses the > CPU might spend a lot of time waiting for memory access. If you get a > lot of one type of instruction in a row some parts of the CPU might be > sitting idle. Depending on the logical flow you might get a larger or > smaller number of speculative execution misses that result in waiting > for the pipeline to be flushed. This can result in the power > consumption of the CPU varying even if it is "100% busy." It could be > 100% busy executing 1 instruction per clock, or it could be 100% busy > executing 4 instructions per clock. Either way the processor queue is > 100% blocked, but the instructions are being retired at different > rates. Modern CPUs can reduce the power consumption by idle > components so part of a CPU core can be using its maximum power draw > while another part of the same core can be using very little power. > The end result of this at scale is that the CPU can produce different > amounts of heat at 100% use depending on what it is actually doing. > > I'm sure people have written about this extensively because it is very > important with benchmarking. When individually given a two uniform > set of tasks a CPU might execute a certain number of tasks per second, > but.when you combine the two sets of tasks and run them in parallel > the CPU might actually be able to perform more tasks per second > combined, because it is better able to utilize all of its components. > A lot of synthetic loads may not fully load the CPU unless it was > designed to balance the types of instructions generated. Natural > loads often fail to load a CPU fully due to the need for IO waiting. > > So, I guess we can get back to your original question. Generally 100% > load means that from the kernel scheduler's perspective the CPU has > been assigned threads to execute 100% of the time. A thread could be > a big string of no-op instructions and from the kernel's perspective > that CPU core is 100% busy since it isn't available to assign other > threads to. > > -- > Rich >
Hi Rich, simply: WHOW! :) Thanks a lot, Sir! ::)) That helps ! Cheers! Meino
