`Am Dienstag, 16. Oktober 2007 schrieb Balbir Singh:> I am trying to think out loud as to what the root cause of the problem> might be. In one of the discussion threads, I saw utime going backwards,> which seemed very odd, I suspect that those are rounding errors.> > I don't understand your explanation below> > Initially utime = 9, stime = 0, sum_exec_runtime = S1> > Later> > utime = 9, stime = 1, sum_exec_runtime = S2> > We can be sure that S >= (utime + stime)I think here is the problem. How can we be sure? We cant. utime and stimeare sampled, so they can be largely off in any direction,if the programsleeps often and manages to synchronize itself to the timer tick. Lets saya program only does a simple system call and then sleeps. So sum_exec_runtimeis increased by lets say 1000 cycles on a 1Ghz box which means 1000ns. If now the timer tick happens exactly at this moment, stime is increased by 1 tick= 1000000ns. Maybe there is some magic in the code which I did not see, but obviouslythe problem exists and looking at Frans data (stime+utime) are not decreasing,but stime isnt and utime is. If you look at Frans data you see:Oct 16 11:54:48 8 10Oct 16 11:54:49 6 12  <-- utimeOct 16 11:54:50 6 12Oct 16 11:54:51 6 12Oct 16 11:54:52 8 10  <-- stimeOct 16 11:54:53 8 10Oct 16 11:54:54 8 10Oct 16 11:54:55 8 12Oct 16 11:54:56 8 12(stime+utime) is constant. That means that S2-S1 is obviously smaller thanone tick (See the calculation in task_stime). I am quite sure it is causedby changes in the sampled values p->utime and p->stime.> > If S2 = S1 + delta, then as per our calculation> > Initially> > utime_proc = (utime * (S1))/(utime + stime)>            = nsec_to_clock_t(9 * S1 / 9)> > later> > utime_proc = nsec_to_clock_t(9 * S2/10)> > Given that S >= (utime + stime), we should be fine.-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`