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 76AB11382C5 for ; Tue, 9 Jun 2020 11:07:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1D01FE086C; Tue, 9 Jun 2020 11:06:58 +0000 (UTC) Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) (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 C48DDE0845 for ; Tue, 9 Jun 2020 11:06:57 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id o15so21852745ejm.12 for ; Tue, 09 Jun 2020 04:06:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u6oiRdx+fG7nBUE9DqGQQG17Keft9WcT8RlNIAafnv4=; b=Tzk4baEk2iiDP5/olT2Bi52zi5sjMjR4PdRfefPeQTeOc2Is6Hna/g6qB8g+u96QSf /2srxhzk+6tRE6zeNSYbegH5j9zxfeLmfEWId6jv0g+NrEhI2lypTtjwVQPt6ec9Puc2 G0oW97rLCsW8xIMjg35djP2LpnZXBuCYq7xi41RXOz3BeLBZJPdFX2hrA5FLaxIlYbDu MGZmM6dgCczyjQZ1uvbOhXpczsUFXX3nhhzqQxPwcVAxpCaY+KFasbdKFU6dJFvDK+vU AON7Zig+BQGtDdxzgP5SHsg+uYtUiNpvxjd3q2aGqY2Kvinwn+1RMH7gqw1fMo35Va3g pHTQ== X-Gm-Message-State: AOAM530CgscADah7XXLGuQlhwJbFVmfQVegDprDPx+yyK/iutnUw390E pH2wtY/ZdoItKTjDV0Y3H4hccmM6lD94tT5mySEnttap X-Google-Smtp-Source: ABdhPJwv82lwKF3vZds09uifJL7XeI67WfxbHha6S+U66Qzi6IfG/2RSrVW3TVfRS3Yk5Awly/y3J4GmpJvF7C8IzcU= X-Received: by 2002:a17:906:e05:: with SMTP id l5mr26707139eji.318.1591700815968; Tue, 09 Jun 2020 04:06:55 -0700 (PDT) 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 References: <20200609091728.lgiekzccyqw4pgln@solfire> In-Reply-To: <20200609091728.lgiekzccyqw4pgln@solfire> From: Rich Freeman Date: Tue, 9 Jun 2020 07:06:45 -0400 Message-ID: Subject: Re: [gentoo-user] 100% CPU load is different to 100% CPU load? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 6a827c36-4d78-445b-91ee-554264646c8b X-Archives-Hash: 00ccaefa36337240eaa6f132499dcec5 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