From: Ingo Molnar <mingo@kernel.org>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
hpa@zytor.com, rostedt@goodmis.org, akpm@linux-foundation.org,
tglx@linutronix.de,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC 4/4] cputime: remove scaling
Date: Wed, 10 Apr 2013 14:02:28 +0200 [thread overview]
Message-ID: <20130410120228.GC8083@gmail.com> (raw)
In-Reply-To: <1364489605-5443-5-git-send-email-sgruszka@redhat.com>
* 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
next prev parent reply other threads:[~2013-04-10 12:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 16:53 [RFC 0/4] do not make cputime scaling in kernel Stanislaw Gruszka
2013-03-28 16:53 ` [RFC 1/4] cputime: change parameter of thread_group_cputime_adjusted Stanislaw Gruszka
2013-03-28 16:53 ` [RFC 2/4] procfs: add sum_exec_runtime to /proc/PID/stat Stanislaw Gruszka
2013-03-28 16:53 ` [RFC 3/4] sched,proc: add csum_sched_runtime Stanislaw Gruszka
2013-03-28 16:53 ` [RFC 4/4] cputime: remove scaling Stanislaw Gruszka
2013-04-10 12:02 ` Ingo Molnar [this message]
2013-04-10 14:29 ` H. Peter Anvin
2013-04-11 8:37 ` Stanislaw Gruszka
2013-04-11 15:19 ` H. Peter Anvin
2013-04-11 8:36 ` Stanislaw Gruszka
2013-04-11 15:06 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130410120228.GC8083@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sgruszka@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.