All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Pop <elendil@planet.nl>
To: balbir@linux.vnet.ibm.com
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Chuck Ebbert <cebbert@redhat.com>, Greg KH <greg@kroah.com>,
	stable@kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [stable] 2.6.23 regression: top displaying 9999% CPU usage
Date: Mon, 29 Oct 2007 13:05:51 +0100	[thread overview]
Message-ID: <200710291305.52992.elendil@planet.nl> (raw)
In-Reply-To: <4714B5BF.1090001@linux.vnet.ibm.com>

Hello Balbir,

On Tuesday 16 October 2007, Balbir Singh wrote:
> Christian Borntraeger wrote:
> > Am Dienstag, 16. Oktober 2007 schrieb Balbir Singh:
> >> I am trying to think out loud as to what the root cause of the problem
> >> might be. In one of the discussion threads, I saw utime going
> >> backwards, which seemed very odd, I suspect that those are rounding
> >> errors.
> >>
> >> I don't understand your explanation below
> >>
> >> Initially utime = 9, stime = 0, sum_exec_runtime = S1
> >>
> >> Later
> >>
> >> utime = 9, stime = 1, sum_exec_runtime = S2
> >>
> >> We can be sure that S >= (utime + stime)
> >
> > I think here is the problem. How can we be sure? We cant. utime and
> > stime are sampled, so they can be largely off in any direction,if the
> > program sleeps often and manages to synchronize itself to the timer
> > tick. Lets say a program only does a simple system call and then
> > sleeps. So sum_exec_runtime is increased by lets say 1000 cycles on a
> > 1Ghz box which means 1000ns. If now the timer tick happens exactly at
> > this moment, stime is increased by 1 tick = 1000000ns.
>
> Yes, I thought of that just after I sent out my email. In the case that
> you mention, the utime and stime accounting is incorrect anyway :-)
> I think we need to find a better solution. I was going to propose that
> we round correctly in (the divisions in)
>
> 1. task_utime()
> 2. clock_t_to_cputime()
>
> I suspect we'll need to round task_utime() to p->utime if the value of
> task_utime() < p->utime and the same thing for task_stime(). I've tried
> reproducing the problem on my UML setup without any success. Let me
> try and grab an x86 box.

Any progress on this issue? I noticed that it's still there in current git.

If a better implementation is not expected any time soon, how about an ACK 
on the reversion patch Christian proposed in
http://lkml.org/lkml/2007/10/16/76
so we can at least get rid of the regression?

Thanks,
Frans Pop

  reply	other threads:[~2007-10-29 12:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12 20:31 2.6.23 regression: top displaying 9999% CPU usage Frans Pop
2007-10-12 21:22 ` [stable] " Greg KH
2007-10-13  7:53   ` Frans Pop
2007-10-14 20:36     ` Christian Borntraeger
2007-10-16  8:29       ` Christian Borntraeger
2007-10-16  9:30         ` Balbir Singh
2007-10-16 10:11           ` Frans Pop
2007-10-16 10:38             ` Balbir Singh
2007-10-16 10:34           ` Christian Borntraeger
2007-10-16 12:59             ` Balbir Singh
2007-10-29 12:05               ` Frans Pop [this message]
2007-10-29 12:31                 ` Balbir Singh
2007-10-29 20:04                   ` Ingo Molnar
2007-10-29 20:33                     ` Christian Borntraeger
2007-10-29 20:41                       ` Ingo Molnar
2007-10-29 21:11                         ` Peter Zijlstra
2007-10-29 21:22                         ` Frans Pop
2007-10-29 21:43                     ` Balbir Singh
2007-10-29 23:19                       ` Frans Pop
2007-10-29 23:22                         ` Ingo Molnar
2007-10-30 20:22                           ` Otavio Salvador
2007-10-29 23:24                         ` Balbir Singh
2007-10-30  5:56                       ` Christian Borntraeger
2007-10-30  6:00                         ` Balbir Singh

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=200710291305.52992.elendil@planet.nl \
    --to=elendil@planet.nl \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cebbert@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stable@kernel.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.