Gentoo Archives: gentoo-user

From: tuxic@××××××.de
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] 100% CPU load is different to 100% CPU load?
Date: Tue, 09 Jun 2020 11:38:29
Message-Id: 20200609113814.rok64goqafjslwtd@solfire
In Reply to: Re: [gentoo-user] 100% CPU load is different to 100% CPU load? by Rich Freeman
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