forked from luck/tmp_suning_uos_patched
3dc167ba57
People report that utime and stime from /proc/<pid>/stat become very wrong when the numbers are big enough, especially if you watch these counters incrementally. Specifically, the current implementation of: stime*rtime/total, results in a saw-tooth function on top of the desired line, where the teeth grow in size the larger the values become. IOW, it has a relative error. The result is that, when watching incrementally as time progresses (for large values), we'll see periods of pure stime or utime increase, irrespective of the actual ratio we're striving for. Replace scale_stime() with a math64.h helper: mul_u64_u64_div_u64() that is far more accurate. This also allows architectures to override the implementation -- for instance they can opt for the old algorithm if this new one turns out to be too expensive for them. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200519172506.GA317395@hirez.programming.kicks-ass.net |
||
|---|---|---|
| .. | ||
| cordic.c | ||
| div64.c | ||
| gcd.c | ||
| int_pow.c | ||
| int_sqrt.c | ||
| Kconfig | ||
| lcm.c | ||
| Makefile | ||
| prime_numbers.c | ||
| rational.c | ||
| reciprocal_div.c | ||