* Christian Borntraeger <borntraeger@de.ibm.com> wrote:

quoted text
> Why does it still shows numbers going backwards? I guess the sampled 
> values for stime and utime change in flight between task_utime and 
> task_stime are called. Lets say utime will be increased. Given the 
> same sum_exec_runtime that means that the result of task_stime() will 
> get smaller at this point.
> 
> So Chucks patch only deals with sum_exec_runtime changing.

basically sum_exec_runtime is split up to form a precise utime/stime, 
using the stime/utime ratio as the factor.

quoted text
> > It seems to me that this patch would be the best option for 2.6.23.
> 
> Ingo, do you have any opinion about how to proceed?

the problem occurs when there's a different "split" dictated by 
p->stime/p->utime. The sum of stime+utime as reported should be 
monotonic, but the individual components may not. (the reason is that we 
have a precise "sum" for free, given by the scheduler, but we do not 
want the overhead of per-syscall timestamps to get a precise stime/utime 
numbers. So we sample p->stime and p->utime from the scheduler tick.)

	Ingo
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/