linux-kernel - Re: [stable] 2.6.23 regression: top displaying 9999% CPU usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200710292222.42688.elendil@planet.nl>
Date:	Mon, 29 Oct 2007 22:22:41 +0100
From:	Frans Pop <elendil@...net.nl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christian Borntraeger <borntraeger@...ibm.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Chuck Ebbert <cebbert@...hat.com>, Greg KH <greg@...ah.com>,
	stable@...nel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [stable] 2.6.23 regression: top displaying 9999% CPU usage

On Monday 29 October 2007, Ingo Molnar wrote:
> * Christian Borntraeger <borntraeger@...ibm.com> wrote:
> > > -	return clock_t_to_cputime(utime);
> > > +	p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
> > > +	return p->prev_utime;
> > >  }
> >
> > [...]
> >
> > I dont think it will work. It will make utime monotic, but stime can
> > still decrease. For example let sum_exec_runtime increase by a tiny
> > little bit while utime will get a full additional tick. stime is
> > sum-utime. So stime can still go backwards. So I think that we need
> > this kind of logic for stime as well, no?
>
> yeah, probably. Peter?

Yes, definitely :-)

With this patch stime is still all over the place.

Oct 29 22:12:39 314 64
Oct 29 22:12:40 392 68
Oct 29 22:12:41 408 67  <--
Oct 29 22:12:42 410 67
Oct 29 22:12:43 416 68
Oct 29 22:12:44 420 68
Oct 29 22:12:45 424 68
Oct 29 22:12:46 426 68
Oct 29 22:12:47 430 70
Oct 29 22:12:48 430 70
Oct 29 22:12:49 430 70
Oct 29 22:12:50 432 68  <--
Oct 29 22:12:51 432 69
Oct 29 22:12:52 432 69
Oct 29 22:12:53 432 69
Oct 29 22:12:54 432 69
Oct 29 22:12:55 432 69
Oct 29 22:12:56 433 70
Oct 29 22:12:57 434 69  <--
Oct 29 22:12:58 443 71

utime looks OK now, though I'd like to test it a bit more (when stime is 
fixed too) before giving a final verdict on that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/