sched/cputime: Fix NO_HZ_FULL getrusage() monotonicity regression

Mike reports:

 Roughly 10% of the time, ltp testcase getrusage04 fails:
 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:

And tracked it down to the case where the task simply doesn't get
_any_ [us]time ticks.

Update the code to assume all rtime is utime when we lack information,
thus ensuring a task that elides the tick gets time accounted.

Reported-by: Mike Galbraith <>
Tested-by: Mike Galbraith <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Frederic Weisbecker <>
Cc: Fredrik Markstrom <>
Cc: Linus Torvalds <>
Cc: Paolo Bonzini <>
Cc: Peter Zijlstra <>
Cc: Radim <>
Cc: Rik van Riel <>
Cc: Stephane Eranian <>
Cc: Thomas Gleixner <>
Cc: Vince Weaver <>
Cc: Wanpeng Li <>
Cc: # 4.3+
Fixes: 9d7fb0427648 ("sched/cputime: Guarantee stime + utime == rtime")
Signed-off-by: Ingo Molnar <>
1 file changed