Messages in this thread | | | Date | Mon, 2 Sep 2013 17:24:31 +0300 | From | Sergey Senozhatsky <> | Subject | Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat |
| |
On (09/02/13 16:13), Frederic Weisbecker wrote: > > On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote: > > > > Hope this may help. > > > > I've added a silly check to make sure that `stime < rtime' > > > > > > > > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr, > > > > if (total) { > > > > stime = scale_stime((__force u64)stime, > > > > (__force u64)rtime, (__force u64)total); > > > > + if (stime > rtime) { > > > > + printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n", stime, rtime); > > > > + WARN_ON(1); > > > > + } > > > > utime = rtime - stime; > > > > } else { > > > > stime = rtime; > > [snip] > > > > > Thanks a lot Sergey for testing this further! > > > > > > Interesting results, so rtime is always one or two units off stime after scaling. > > > Stanislaw made the scaling code with Linus and he has a better idea on the math guts > > > here. > > > > I don't think this is scale issue, but rather at scale_stime() input > > stime is already bigger then rtime. Sergey, could you verify that > > by adding check before scale_stime() ? > > Note that having stime > rtime should be fine to handle. This can happen for > example if the task runs on tiny timeslices but is unlucky enough that all these > timeslices are interrupted by the tick. >
even is stime > rtime, scale_stime() fixes it:
if (stime > rtime) swap(rtime, stime);
-ss
| |