2013/4/9 <a...@linux-foundation.org>: > > The patch titled > Subject: posix_timers: Remove dead task timer expiry caching > has been added to the -mm tree. Its filename is > posix_timers-remove-dead-task-timer-expiry-caching.patch > > Before you just go and hit "reply", please: > a) Consider who else should be cc'ed > b) Prefer to cc a suitable mailing list as well > c) Ideally: find the original patch on the mailing list and do a > reply-to-all to that, adding suitable additional cc's > > *** Remember to use Documentation/SubmitChecklist when testing your code *** > > The -mm tree is included into linux-next and is updated > there every 3-4 working days > > ------------------------------------------------------ > From: Frederic Weisbecker <fweis...@gmail.com> > Subject: posix_timers: Remove dead task timer expiry caching > > When reading a timer sample, posix_cpu_timer_get() and > posix_cpu_timer_schedule() both perform a caching of the timer expiry time > by converting its value from absolute to relative if the task has exited. > > The reason for this caching is not clear though, it could be: > > 1) For performance reasons: no need to calculate the delta after the > task has died, its cputime won't change anymore. We can thus avoid > some locking (sighand, tasklist_lock, rq->lock for task_delta_exec(), > ...), and various operations to calculate the sample... > > 2) To keep the remaining delta for the timer available after the task > has died. When it gets reaped, its sighand disappears, so accessing > the process wide cputime through tsk->signal is probably not safe. > > Now, is the first reason really worth it? I have no idea if it is a case > we really want to optimize. > > Considering the second reason, we return a disarmed zero'ed timer when > tsk->sighand == NULL. So if this is an assumed reason, it's broken. And > this case only concern process wide timers that have their group leader > reaped. The posix cpu timer shouldn't even be available anymore at that > time. Unless the group leader changed since we called > posix_cpu_timer_create() after an exec? > > Anyway for now I'm sending this as an RFC because there may well be subtle > things I left behind. > > Signed-off-by: Frederic Weisbecker <fweis...@gmail.com> > Cc: Stanislaw Gruszka <sgrus...@redhat.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Peter Zijlstra <a.p.zijls...@chello.nl> > Cc: Ingo Molnar <mi...@elte.hu> > Cc: Oleg Nesterov <o...@redhat.com> > Signed-off-by: Andrew Morton <a...@linux-foundation.org>
So this very patch probably shouldn't go to 3.10, I sent it early in case I could get some hindsight from reviewers. Anyway, let me some time to think more about it and all the possible implications against exit, de_thread, etc... then I'll resend if that sounds palatable. Thanks. -- 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/
