I have a patch that does scaling by multiply for 64-bit architectures. I probably should clean it up and send it in. I need to see if it fixes this problem.
Ingo Molnar <mi...@kernel.org> wrote: > >* Stanislaw Gruszka <sgrus...@redhat.com> wrote: > >> Scaling cputime cause problems, bunch of them was fixed, but still is >possible >> to hit multiplication overflow issue, which make {u,s}time values >incorrect. >> This problem has no good solution in kernel. > >Wasn't 128-bit math a solution to the overflow problems? 128-bit math >isn't nice, >but at least for multiplication it's defensible. > >> This patch remove scaling code and export raw values of {u,t}ime . >Procps >> programs can use newly introduced sum_exec_runtime to find out >precisely >> calculated process cpu time and scale utime, stime values >accordingly. >> >> Unfortunately times(2) syscall has no such option. >> >> This change affect kernels compiled without >CONFIG_VIRT_CPU_ACCOUNTING_*. > >So, the concern here is that 'top hiding' code can now hide again. It's >also that >we are not really solving the problem, we are pushing it to user-space >- which in >the best case gets updated to solve the problem in some similar fashion >- and in >the worst case does not get updated or does it in a buggy way. > >So while user-space has it a bit easier because it can do floating >point math, is >there really no workable solution to the current kernel side integer >overflow bug? >I really prefer robust kernel side accounting/instrumentation. > >Thanks, > > Ingo -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/