>> @@ -250,8 +250,13 @@ void thread_group_cputimer(struct task_struct *tsk, >> struct task_cputime *times) >> * values through the TIMER_ABSTIME flag, therefore we have >> * to synchronize the timer to the clock every time we start >> * it. >> + * >> + * Do not add the current delta, because >> + * account_group_exec_runtime() will also this delta and we >> + * wouldn't want to double account time and get ahead of >> + * ourselves. >> */ >> - thread_group_cputime(tsk, &sum); >> + thread_group_cputime(tsk, false, &sum); >> raw_spin_lock_irqsave(&cputimer->lock, flags); > > I wonder if we should move thread_group_cputime() inside this lock. > Otherwise we can miss some updates in-between.
Hmm.. I don't agree with this. Right, we can miss some updates. But 1) cputimer->lock doesn't prevent any update update_curr() only take rq_lock, and 2) POSIX timer and sleeping semantics allow longer sleep than an argument. Then, the missing is safe, nobody can observe which of the timer_setime() syscall and update_curr() happened earlier. Ah, I'm now finding when update_gt_cputime() effectively work. It helps to avoid timer_settime() vs timer_settime() mess. -- 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/