1 |
On 06/09 07:06, Rich Freeman wrote: |
2 |
> On Tue, Jun 9, 2020 at 5:17 AM <tuxic@××××××.de> wrote: |
3 |
> > |
4 |
> > What is the difference between 100% CPU load and 100% CPU load to |
5 |
> > create such an difference in temperature? |
6 |
> > How is X% load calculated? |
7 |
> > |
8 |
> |
9 |
> I think a lot more detail around what you're actually running would be |
10 |
> needed to provide more insight here. I can think of a few things that |
11 |
> could cause this: |
12 |
> |
13 |
> The kernel maintains a number of stats around CPU load including % |
14 |
> utilized by userspace, the kernel, IRQs, IO waiting, and truly idle |
15 |
> time. Depending on where you were getting that "100%" figure I can't |
16 |
> be sure what was included in that. If it was just 100-idle then you |
17 |
> could have had IO waiting included in the load - this is time when you |
18 |
> have a running process that wants to do something but it is blocked on |
19 |
> IO, such as reading from a disk. If you have 12 threads all doing |
20 |
> random IO from a spinning hard disk you can easily end up with the CPU |
21 |
> spending a whole lot of time doing nothing, but where it is otherwise |
22 |
> "busy." If the stat was system+user then that reflects actual CPU |
23 |
> processing activity. |
24 |
> |
25 |
> Next, not all instructions are created equally, and a CPU core is a |
26 |
> fairly complex device that has many subdivisions. There are circuits |
27 |
> that do nothing but integer or floating-point math, others that |
28 |
> fetch/store data, some that do logical comparisons, and so on. While |
29 |
> the OS tries to keep all the CPU cores busy, the CPU core itself also |
30 |
> tries to keep all of its components busy (something aided by |
31 |
> optimizing compilers). However, the CPU only has so many instructions |
32 |
> in the pipeline at one time, and they often have interdependencies, |
33 |
> and so the CPU can only use out-of-order execution to a limited degree |
34 |
> to keep all its parts active. If you get a lot of cache misses the |
35 |
> CPU might spend a lot of time waiting for memory access. If you get a |
36 |
> lot of one type of instruction in a row some parts of the CPU might be |
37 |
> sitting idle. Depending on the logical flow you might get a larger or |
38 |
> smaller number of speculative execution misses that result in waiting |
39 |
> for the pipeline to be flushed. This can result in the power |
40 |
> consumption of the CPU varying even if it is "100% busy." It could be |
41 |
> 100% busy executing 1 instruction per clock, or it could be 100% busy |
42 |
> executing 4 instructions per clock. Either way the processor queue is |
43 |
> 100% blocked, but the instructions are being retired at different |
44 |
> rates. Modern CPUs can reduce the power consumption by idle |
45 |
> components so part of a CPU core can be using its maximum power draw |
46 |
> while another part of the same core can be using very little power. |
47 |
> The end result of this at scale is that the CPU can produce different |
48 |
> amounts of heat at 100% use depending on what it is actually doing. |
49 |
> |
50 |
> I'm sure people have written about this extensively because it is very |
51 |
> important with benchmarking. When individually given a two uniform |
52 |
> set of tasks a CPU might execute a certain number of tasks per second, |
53 |
> but.when you combine the two sets of tasks and run them in parallel |
54 |
> the CPU might actually be able to perform more tasks per second |
55 |
> combined, because it is better able to utilize all of its components. |
56 |
> A lot of synthetic loads may not fully load the CPU unless it was |
57 |
> designed to balance the types of instructions generated. Natural |
58 |
> loads often fail to load a CPU fully due to the need for IO waiting. |
59 |
> |
60 |
> So, I guess we can get back to your original question. Generally 100% |
61 |
> load means that from the kernel scheduler's perspective the CPU has |
62 |
> been assigned threads to execute 100% of the time. A thread could be |
63 |
> a big string of no-op instructions and from the kernel's perspective |
64 |
> that CPU core is 100% busy since it isn't available to assign other |
65 |
> threads to. |
66 |
> |
67 |
> -- |
68 |
> Rich |
69 |
> |
70 |
|
71 |
Hi Rich, |
72 |
|
73 |
simply: WHOW! :) |
74 |
Thanks a lot, Sir! ::)) |
75 |
|
76 |
That helps ! |
77 |
|
78 |
Cheers! |
79 |
Meino |