Messages in this thread | | | Subject | Re: [RFC 4/4] cputime: remove scaling | From | "H. Peter Anvin" <> | Date | Wed, 10 Apr 2013 07:29:21 -0700 |
| |
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 <mingo@kernel.org> wrote:
> >* Stanislaw Gruszka <sgruszka@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.
| |