On Mon, 2008-09-08 at 00:02 +0200, Rafael J. Wysocki wrote: > On Sunday, 7 of September 2008, Peter Zijlstra wrote: > > On Sat, 2008-09-06 at 23:30 +0200, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.26. Please verify if it still should be listed and let me know > > > (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11209 > > > Subject : 2.6.27-rc1 process time accounting > > > Submitter : Lukas Hejtmanek <xhejtman@xxxxxxxxxxx> > > > Date : 2008-07-31 10:43 (38 days old) > > > References : http://marc.info/?l=linux-kernel&m=121750102917490&w=4 > > > Handled-By : Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> > > > > Should be fixed in the latest -git > > Thanks for the update. > > Does any specific commit fix it or just a series of recent commits? commit 49048622eae698e5c4ae61f7e71200f265ccc529 Author: Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> Date: Fri Sep 5 18:12:23 2008 +0200 sched: fix process time monotonicity Spencer reported a problem where utime and stime were going negative despite the fixes in commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. The suspected reason for the problem is that signal_struct maintains it's own utime and stime (of exited tasks), these are not updated using the new task_utime() routine, hence sig->utime can go backwards and cause the same problem to occur (sig->utime, adds tsk->utime and not task_utime()). This patch fixes the problem commit 56c7426b3951e4f35a71d695f1c982989399d6fd Author: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> Date: Mon Sep 1 16:44:23 2008 +0200 sched_clock: fix NOHZ interaction If HLT stops the TSC, we'll fail to account idle time, thereby inflating the actual process times. Fix this by re-calibrating the clock against GTOD when leaving nohz mode. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
