Due to rounding in scale_stime(), for big numbers, scaled stime values
will grow in chunks. Since rtime grow in jiffies and we calculate utime
like below:
prev->stime = max(prev->stime, stime);
prev->utime = max(prev->utime, rtime - prev->stime);
we could erroneously account stime values as utime. To prevent that only
update prev->{u,s}time values when they are smaller than current rtime.
Signed-off-by: Stanislaw Gruszka <sgrus...@redhat.com>
---
kernel/sched/cputime.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index b3dd984..3f192bf 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -581,6 +581,14 @@ static void cputime_adjust(struct task_cputime *curr,
*/
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;
+
if (!rtime) {
stime = 0;
} else if (!total) {
@@ -598,6 +606,7 @@ static void cputime_adjust(struct task_cputime *curr,
prev->stime = max(prev->stime, stime);
prev->utime = max(prev->utime, rtime - prev->stime);
+out:
*ut = prev->utime;
*st = prev->stime;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
