Messages in this thread | | | Subject | Re: [PATCH] fix granularity of task_u/stime(), v2 | From | Peter Zijlstra <> | Date | Tue, 17 Nov 2009 14:24:48 +0100 |
| |
On Tue, 2009-11-17 at 14:08 +0100, Stanislaw Gruszka wrote: > On Mon, Nov 16, 2009 at 12:32:43PM -0700, Spencer Candland wrote: > > > seems you have more test cases for utime decreasing issues, > > > could you send links to me ? Somehow I could not find them > > > by my own. Particularly test case used in development this commit > > > is interested: > > > > > > commit 49048622eae698e5c4ae61f7e71200f265ccc529 > > > Author: Balbir Singh <balbir@linux.vnet.ibm.com> > > > Date: Fri Sep 5 18:12:23 2008 +0200 > > > sched: fix process time monotonicity > > > > I had originally noticed that in a production web server, so my test > > case was designed to mirror what I was seeing there, which was just > > running apache with worker mpm, and running a simple apache bench while > > watching the utime/stime of the apache children. Unfortunately that > > method was not terribly reliable at reproducing the issue, which is why > > I felt it necessary to try to come up with a better test case this time > > around. > > No wonder I could not find anything on google and in mailing list > archives :) > > Seems issue reported then was exactly the same as reported now by > you. Looks like commit 49048622eae698e5c4ae61f7e71200f265ccc529 just > make probability of bug smaller and you did not note it until now. > > Could you please test this patch, if it solve all utime decrease > problems for you: > > http://patchwork.kernel.org/patch/59795/ > > If you confirm it work, I think we should apply it. Otherwise > we need to go to propagate task_{u,s}time everywhere, which is not > (my) preferred solution.
That patch will create another issue, it will allow a process to hide from top by arranging to never run when the tick hits.
| |