public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [GIT PULL] sched: Cputime update for 3.10
Date: Thu, 14 Mar 2013 10:13:43 +0100	[thread overview]
Message-ID: <20130314091342.GB1377@redhat.com> (raw)
In-Reply-To: <20130314071427.GB7869@gmail.com>

On Thu, Mar 14, 2013 at 08:14:27AM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > Ingo,
> > 
> > Please pull the latest cputime accounting updates that can be found at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > 	sched/core
> > 
> > HEAD: d9a3c9823a2e6a543eb7807fb3d15d8233817ec5
> > 
> > Some users are complaining that their threadgroup's runtime accounting 
> > freezes after a week or so of intense cpu-bound workload. This set tries 
> > to fix the issue by reducing the risk of multiplication overflow in the 
> > cputime scaling code.
> 
> Hm, is this a new bug? When was it introduced and is upstream affected as 
> well?

Commit 0cf55e1ec08bb5a22e068309e2d8ba1180ab4239 start to use scalling
for whole thread group, so increase chances of hitting multiplication
overflow, depending on how many CPUs are on the system.

We have multiplication utime * rtime for one thread since commit
b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. 

Overflow will happen after:

rtime * utime > 0xffffffffffffffff jiffies

if thread utilize 100% of CPU time, that gives:

rtime > sqrt(0xffffffffffffffff) jiffies

ritme > sqrt(0xffffffffffffffff) / (24 * 60 * 60 * HZ) days

For HZ 100 it will be 497 days for HZ 1000 it will be 49 days.

Bug affect only users, who run CPU intensive application for that
long period. Also they have to be interested on utime,stime values,
as bug has no other visible effect as making those values incorrect.

Stanislaw

  reply	other threads:[~2013-03-14  9:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-13 17:44 [GIT PULL] sched: Cputime update for 3.10 Frederic Weisbecker
2013-03-13 17:44 ` [PATCH 1/2] math64: New div64_u64_rem helper Frederic Weisbecker
2013-03-13 17:44 ` [PATCH 2/2] sched: Lower chances of cputime scaling overflow Frederic Weisbecker
2013-03-14  7:14 ` [GIT PULL] sched: Cputime update for 3.10 Ingo Molnar
2013-03-14  9:13   ` Stanislaw Gruszka [this message]
2013-03-14 12:39     ` Frederic Weisbecker
2013-03-18  9:13 ` Ingo Molnar

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=20130314091342.GB1377@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox