[gentoo-user] 100% CPU load is different to 100% CPU load?

[gentoo-user] 100% CPU load is different to 100% CPU load?

[tuxic]

Hi,

yesterday I md5summed my hole system with find.....|
xargs....md5sum....

With options I set xargs to use all 12 thread and use as much args per
call as possible in one line.

After a while I checked the CPU with glance and it shows, that all
12 cores/threads were "loaded" with 100% each constantly over a
period of about 1h. The CPU temperature rises to about 47°C.

The CPU does not contain a GPU. Graphics goes extra.

Today I created again a CPU load over a comparable duration with
a constant 100% CPU load on each core/thread.

Interesting it does not take more than 3 minutes to reach 65°C CPU
temperature.

Both temperatures reflect the die temperature.

What is the difference between 100% CPU load and 100% CPU load to
create such an difference in temperature?
How is X% load calculated?

Cheers!
Meino

Re: [gentoo-user] 100% CPU load is different to 100% CPU load?

[Rich Freeman]

On Tue, Jun 9, 2020 at 5:17 AM <tuxic@posteo.de> 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

Re: [gentoo-user] 100% CPU load is different to 100% CPU load?

[tuxic]

On 06/09 07:06, Rich Freeman wrote:
> On Tue, Jun 9, 2020 at 5:17 AM <tuxic@posteo.de> 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