public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Vik Heyndrickx <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: efault@gmx.de, tglx@linutronix.de, linux-kernel@vger.kernel.org,
	hpa@zytor.com, vik.heyndrickx@veribox.net,
	torvalds@linux-foundation.org, dsmythies@telus.net,
	mingo@kernel.org, peterz@infradead.org
Subject: [tip:sched/urgent] sched: Fix non-zero idle loadavg
Date: Thu, 21 Jan 2016 10:54:45 -0800	[thread overview]
Message-ID: <tip-1f9649ef6aa1bac53fb478d9e641b22d67f8423c@git.kernel.org> (raw)
In-Reply-To: <56A0A38D.4040900@veribox.net>

Commit-ID:  1f9649ef6aa1bac53fb478d9e641b22d67f8423c
Gitweb:     http://git.kernel.org/tip/1f9649ef6aa1bac53fb478d9e641b22d67f8423c
Author:     Vik Heyndrickx <vik.heyndrickx@veribox.net>
AuthorDate: Thu, 21 Jan 2016 10:23:25 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Thu, 21 Jan 2016 18:55:23 +0100

sched: Fix non-zero idle loadavg

Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
have no load at all.

Uptime and /proc/loadavg on all systems with kernels released during the
last five years up until kernel version 4.4, show a 5- and 15-minute
minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
idle systems, but the way the kernel calculates this value prevents it
from getting lower than the mentioned values.

Likewise but not as obviously noticeable, a fully loaded system with
no processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99,
0.95 (multiplied by number of cores).

By removing the single code line that performed a rounding on the
internally kept load value, effectively returning this function
calc_load to its state it had before, the visualization problem is
completely fixed.

Once the (old) load becomes 93 or higher, it mathematically can never
get lower than 93, even when the active (load) remains 0 forever.
This results in the strange 0.00, 0.01, 0.05 uptime values on idle
systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.

It is not correct to add a 0.5 rounding (=1024/2048) here, since the
result from this function is fed back into the next iteration again,
so the result of that +0.5 rounding value then gets multiplied by
(2048-2037), and then rounded again, so there is a virtual "ghost"
load created, next to the old and active load terms.

The modified code was tested on nohz=off and nohz kernels. It was tested
on vanilla kernel 4.4 and on centos 7.1 kernel 3.10.0-327. It was tested
on single, dual, and octal cores system. It was tested on virtual hosts
and bare hardware. No unwanted effects have been observed, and the
problems that the patch intended to fix were indeed gone.

Signed-off-by: Vik Heyndrickx <vik.heyndrickx@veribox.net>
[ Changelog edits ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Doug Smythies <dsmythies@telus.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes")
Link: http://lkml.kernel.org/r/56A0A38D.4040900@veribox.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/loadavg.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/loadavg.c b/kernel/sched/loadavg.c
index ef71590..eb83b93 100644
--- a/kernel/sched/loadavg.c
+++ b/kernel/sched/loadavg.c
@@ -101,7 +101,6 @@ calc_load(unsigned long load, unsigned long exp, unsigned long active)
 {
 	load *= exp;
 	load += active * (FIXED_1 - exp);
-	load += 1UL << (FSHIFT - 1);
 	return load >> FSHIFT;
 }
 

      parent reply	other threads:[~2016-01-21 18:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21  9:23 [PATCH] sched: loadavg 0.00, 0.01, 0.05 on idle Vik Heyndrickx
2016-01-21 15:28 ` Peter Zijlstra
2016-01-21 18:38   ` Doug Smythies
2016-01-22  0:43     ` Vik Heyndrickx
2016-01-21 18:54 ` tip-bot for Vik Heyndrickx [this message]

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=tip-1f9649ef6aa1bac53fb478d9e641b22d67f8423c@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=dsmythies@telus.net \
    --cc=efault@gmx.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vik.heyndrickx@veribox.net \
    /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