From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938685AbcHJTwZ (ORCPT ); Wed, 10 Aug 2016 15:52:25 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35131 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935768AbcHJTwR (ORCPT ); Wed, 10 Aug 2016 15:52:17 -0400 Message-ID: <1470827669.15624.16.camel@gmail.com> Subject: [patch] sched/cputime: Fix NO_HZ_FULL getrusage() monotonicity regression From: Mike Galbraith To: Peter Zijlstra Cc: LKML Date: Wed, 10 Aug 2016 13:14:29 +0200 Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, While running ltp, the fates decided it was time for me to encounter the roughly 1 out of every 10 call failure below. As much as I run ltp, I'm a bit surprised that I (or anyone else) haven't met this before, but then the fates are known to be a tad fickle. getrusage04 0 TINFO : Expected timers granularity is 4000 us getrusage04 0 TINFO : Using 1 as multiply factor for max [us]time increment (1000+4000us)! getrusage04 0 TINFO : utime: 0us; stime: 179us getrusage04 0 TINFO : utime: 3751us; stime: 0us getrusage04 1 TFAIL : getrusage04.c:133: stime increased > 5000us: When applying the full rtime to either stime or utime, do not overwrite the previously tallied value. Fixes: 9d7fb0427648 ("sched/cputime: Guarantee stime + utime == rtime") Signed-off-by: Mike Galbraith Cc: stable@vger.kernel.org # 4.3+ --- kernel/sched/cputime.c | 2 ++ 1 file changed, 2 insertions(+) --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -608,11 +608,13 @@ static void cputime_adjust(struct task_c if (utime == 0) { stime = rtime; + utime = prev->utime; goto update; } if (stime == 0) { utime = rtime; + stime = prev->stime; goto update; }