mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: yaozhenguo <yaozhenguo1@gmail.com>
To: tglx@linutronix.de, yaoma@linux.alibaba.com, akpm@linux-foundation.org
Cc: max.kellermann@ionos.com, lihuafei1@huawei.com,
	yaozhenguo@jd.com, linux-kernel@vger.kernel.org,
	ZhenguoYao <yaozhenguo1@gmail.com>
Subject: [PATCH] watchdog/softlockup:Fix incorrect CPU utilization output during softlockup
Date: Tue, 12 Aug 2025 16:25:10 +0800	[thread overview]
Message-ID: <20250812082510.32291-1-yaozhenguo@jd.com> (raw)

From: ZhenguoYao <yaozhenguo1@gmail.com>

Since we use 16-bit precision, the raw data will undergo
integer division, which may sometimes result in data loss.
This can lead to slightly inaccurate CPU utilization calculations.
Under normal circumstances, this isn’t an issue.  However,
when CPU utilization reaches 100%, the calculated result might
exceed 100%.  For example, with raw data like the following:

sample_period 400000134 new_stat 83648414036 old_stat 83247417494

sample_period=400000134/2^24=23
new_stat=83648414036/2^24=4985
old_stat=83247417494/2^24=4961
util=105%

Below log will output:

CPU#3 Utilization every 0s during lockup:
    #1:   0% system,          0% softirq,   105% hardirq,     0% idle
    #2:   0% system,          0% softirq,   105% hardirq,     0% idle
    #3:   0% system,          0% softirq,   100% hardirq,     0% idle
    #4:   0% system,          0% softirq,   105% hardirq,     0% idle
    #5:   0% system,          0% softirq,   105% hardirq,     0% idle

To avoid confusion, we enforce a 100% display cap when
calculations exceed this threshold.

Signed-off-by: ZhenguoYao <yaozhenguo1@gmail.com>
---
 kernel/watchdog.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 9c7134f7d2c4..29787996c69c 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -444,6 +444,13 @@ static void update_cpustat(void)
 		old_stat = __this_cpu_read(cpustat_old[i]);
 		new_stat = get_16bit_precision(cpustat[tracked_stats[i]]);
 		util = DIV_ROUND_UP(100 * (new_stat - old_stat), sample_period_16);
+		/* Since we use 16-bit precision, the raw data will undergo
+		 * integer division, which may sometimes result in data loss,
+		 * and then result might exceed 100%. To avoid confusion,
+		 * we enforce a 100% display cap when calculations exceed this threshold.
+		 */
+		if (util > 100)
+			util = 100;
 		__this_cpu_write(cpustat_util[tail][i], util);
 		__this_cpu_write(cpustat_old[i], new_stat);
 	}
-- 
2.43.5


             reply	other threads:[~2025-08-12  8:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-12  8:25 yaozhenguo [this message]
2025-08-18  2:18 ` Andrew Morton
2025-08-18  8:16   ` Zhenguo Yao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250812082510.32291-1-yaozhenguo@jd.com \
    --to=yaozhenguo1@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=lihuafei1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max.kellermann@ionos.com \
    --cc=tglx@linutronix.de \
    --cc=yaoma@linux.alibaba.com \
    --cc=yaozhenguo@jd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®