From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1D7A21382C5 for ; Tue, 9 Jun 2020 11:38:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D36BBE0856; Tue, 9 Jun 2020 11:38:21 +0000 (UTC) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EE2A3E07C5 for ; Tue, 9 Jun 2020 11:38:20 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id DE800160060 for ; Tue, 9 Jun 2020 13:38:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1591702697; bh=PyF+OjBJovBq8j+7q4b6p0pnMuIUbdFB5Zkh+DnXVHo=; h=Date:From:To:Subject:From; b=ADSx17kezhdf0CGlQmhVxU+8ezAjyLe3iA87Nx5D4mE84EMaZiJVhSaJodYKlN4db jb16JS68dx5fgqO96GnVDcUZDekoSRNSau3oCHh8kipKY06iAS6pFfyEYMdFX66LcK mw81r3KWaeWG4je74egxXGAdm4GOHq9xGPwR7c2h7wvT1MDZHZ1apywbJd494RRVGS x/KuJHQnXbRAKYcuQy8oJ7OyKK5+3lK4JgWuxygtUxpXBzjzl5bqi75p2pPwmS+qVf +7oiiUwByNBfEDqekhZjyopIdq9GwK2Fx9XSCus5DcTD14DDUqe20CG3WLjutCa8iN O4aQGYFft60KA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 49h7RC0KTtz9rxH for ; Tue, 9 Jun 2020 13:38:14 +0200 (CEST) Date: Tue, 9 Jun 2020 13:38:14 +0200 From: tuxic@posteo.de To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] 100% CPU load is different to 100% CPU load? Message-ID: <20200609113814.rok64goqafjslwtd@solfire> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20200609091728.lgiekzccyqw4pgln@solfire> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Archives-Salt: 0aca2091-d2d0-4cee-8959-6a5096268dec X-Archives-Hash: f81714cc6e578f673dae18a7d65a79ba On 06/09 07:06, Rich Freeman wrote: > On Tue, Jun 9, 2020 at 5:17 AM 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