All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.