On Fri, 2013-04-26 at 00:40 -0400, Olivier Langlois wrote: > On Fri, 2013-04-19 at 11:08 -0700, KOSAKI Motohiro wrote: > > On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro > > <kosaki.motoh...@gmail.com> wrote: > > >> I feel we are hitting the same issue than this patch: > > >> https://lkml.org/lkml/2013/4/5/116 > > >> > > >> I'm adding Kosaki in Cc, who proposed roughly the same fix. > > > > > > Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails. > > > However the fix is definitely same and I definitely agree this approach. > > > > > > thank you. > > > > And if I understand correctly, update_gt_cputime() is no longer > > necessary after this patch because time never makes backward. > > > > What do you think? > > Kosaki, I would tend to say that what you propose is exact. After having > added the task deltas I was puzzled to see the cputimer still moving > faster than the process clock. I was seeing it with the the help of > printk statement inside update_gt_cputime(). > > After nailing down the last remaining cause of that inside sched/core.c, > I have never seen after the cputimer being in advance. > I need to add that I can only confirm that to be true with sum_exec_runtime.
To affirm it to be true for stime and utime would require more investigation. I didn't look them at all. I was only concerned with sum_exec_runtime. I will prepare a v2 of the patch accounting all the feedbacks that I received from KOSAKI Motohiro, Frederic Weisbecker and Peter Zijlstra and send it back here for further discussion. Thank you very much all! Olivier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/