Messages in this thread | | | From | Frans Pop <> | Subject | Re: [stable] 2.6.23 regression: top displaying 9999% CPU usage | Date | Mon, 29 Oct 2007 22:22:41 +0100 |
| |
On Monday 29 October 2007, Ingo Molnar wrote: > * Christian Borntraeger <borntraeger@de.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |