Re: [PATCH for testing] Re: Decreasing stime running confuses top

[Ingo Molnar <mingo@elte.hu>]

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

> 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.

> > 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