* Christian Borntraeger <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
