public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Fredrik Markstrom <fredrik.markstrom@gmail.com>
To: mingo@redhat.com, peterz@infradead.org
Cc: linux-kernel@vger.kernel.org,
	Fredrik Markstrom <fredrik.markstrom@gmail.com>
Subject: [PATCH 1/1] cputime: Make the reported utime+stime correspond to the actual runtime.
Date: Fri, 12 Jun 2015 10:55:16 +0200	[thread overview]
Message-ID: <1434099316-29749-2-git-send-email-fredrik.markstrom@gmail.com> (raw)
In-Reply-To: <1434099316-29749-1-git-send-email-fredrik.markstrom@gmail.com>

The scaling mechanism might sometimes cause top to report >100%
(sometimes > 1000%) cpu usage for a single thread. This patch makes
sure that stime+utime corresponds to the actual runtime of the thread.

Signed-off-by: Fredrik Markstrom <fredrik.markstrom@gmail.com>
---
 kernel/sched/cputime.c | 46 +++++++++++++++++++---------------------------
 1 file changed, 19 insertions(+), 27 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index f5a64ff..2d168c8 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -554,22 +554,7 @@ drop_precision:
 	return (__force cputime_t) scaled;
 }
 
-/*
- * Atomically advance counter to the new value. Interrupts, vcpu
- * scheduling, and scaling inaccuracies can cause cputime_advance
- * to be occasionally called with a new value smaller than counter.
- * Let's enforce atomicity.
- *
- * Normally a caller will only go through this loop once, or not
- * at all in case a previous caller updated counter the same jiffy.
- */
-static void cputime_advance(cputime_t *counter, cputime_t new)
-{
-	cputime_t old;
-
-	while (new > (old = READ_ONCE(*counter)))
-		cmpxchg_cputime(counter, old, new);
-}
+static DEFINE_SPINLOCK(prev_time_lock);
 
 /*
  * Adjust tick based cputime random precision against scheduler
@@ -590,17 +575,11 @@ static void cputime_adjust(struct task_cputime *curr,
 	 *
 	 * Fix this by scaling these tick based values against the total
 	 * runtime accounted by the CFS scheduler.
+	 * In addition make sure the reported stime+utime equals rtime
+	 * so that the total runtime reported is correct.
 	 */
 	rtime = nsecs_to_cputime(curr->sum_exec_runtime);
 
-	/*
-	 * Update userspace visible utime/stime values only if actual execution
-	 * time is bigger than already exported. Note that can happen, that we
-	 * provided bigger values due to scaling inaccuracy on big numbers.
-	 */
-	if (prev->stime + prev->utime >= rtime)
-		goto out;
-
 	stime = curr->stime;
 	utime = curr->utime;
 
@@ -616,12 +595,25 @@ static void cputime_adjust(struct task_cputime *curr,
 		utime = rtime - stime;
 	}
 
-	cputime_advance(&prev->stime, stime);
-	cputime_advance(&prev->utime, utime);
+	spin_lock(&prev_time_lock);
+	if (stime < prev->stime) {
+		stime = prev->stime;
+		utime = rtime - stime;
+	} else if (utime < prev->utime) {
+		utime = prev->utime;
+		stime = rtime - utime;
+	}
+	WARN_ON(stime < prev->stime);
+	WARN_ON(utime < prev->utime);
+	WARN_ON(stime + utime != rtime);
 
-out:
+	if (prev->stime + prev->utime < rtime) {
+		prev->stime = stime;
+		prev->utime = utime;
+	}
 	*ut = prev->utime;
 	*st = prev->stime;
+	spin_unlock(&prev_time_lock);
 }
 
 void task_cputime_adjusted(struct task_struct *p, cputime_t *ut, cputime_t *st)
-- 
1.9.1


  reply	other threads:[~2015-06-12  8:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12  8:55 [PATCH 0/1] cputime: Make the reported utime+stime correspond to the actual runtime Fredrik Markstrom
2015-06-12  8:55 ` Fredrik Markstrom [this message]
2015-06-12 10:16   ` [PATCH 1/1] " Peter Zijlstra
2015-06-12 11:01     ` Peter Zijlstra
2015-06-15 15:34       ` Fredrik Markström
2015-06-16 14:35         ` Fredrik Markström
2015-06-29 14:58         ` Peter Zijlstra
2015-06-29 15:28           ` Fredrik Markström
2015-06-29 18:54             ` Jason Low
2015-06-29 19:08               ` Fredrik Markström
2015-06-29 22:11                 ` Jason Low
2015-06-30  9:30             ` Peter Zijlstra
2015-06-30 11:50               ` Fredrik Markström
2015-06-30 12:18                 ` Peter Zijlstra
2015-06-30 18:30                   ` Fredrik Markström
2015-07-02 12:11                     ` Peter Zijlstra
2015-07-02 13:07                       ` Peter Zijlstra
2015-07-07  0:51                         ` Frederic Weisbecker
2015-07-07  7:59                           ` Peter Zijlstra
2015-07-07  8:09                             ` Peter Zijlstra
2015-07-07 12:10                               ` Fredrik Markström
2015-07-07 15:37                                 ` Peter Zijlstra
2015-07-07 13:34                               ` Frederic Weisbecker
2015-07-07 15:34                                 ` Peter Zijlstra
2015-07-07 16:26                                   ` Frederic Weisbecker
2015-06-13 11:17     ` Fredrik Markström

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=1434099316-29749-2-git-send-email-fredrik.markstrom@gmail.com \
    --to=fredrik.markstrom@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /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