Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-05-06 Thread Frederic Weisbecker
On Tue, Apr 30, 2013 at 01:51:58PM -0400, Olivier Langlois wrote: > > > > > > Maybe the condition around the posix_cpu_timer_schedule() block inside > > > cpu_timer_fire() could even be a good candidate for 'unlikely' > > > qualifier. > > > > Well, cpu_timer_fire() is probably not a fast path. S

Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-30 Thread Olivier Langlois
> > > Maybe the condition around the posix_cpu_timer_schedule() block inside > > cpu_timer_fire() could even be a good candidate for 'unlikely' > > qualifier. > > Well, cpu_timer_fire() is probably not a fast path. So helping branch > prediction there probably won't have much measurable effect i

Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-30 Thread Frederic Weisbecker
On Fri, Apr 26, 2013 at 12:27:59AM -0400, Olivier Langlois wrote: > On Fri, 2013-04-19 at 14:47 +0200, Frederic Weisbecker wrote: > > > > > > > > > I might be mistaken but I believe that firing timers are not rescheduled > > > in the current interrupt context. They are going to be rescheduled lat

Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-25 Thread Olivier Langlois
> > > IMO, a more likely scenario, posix_cpu_timer_schedule() will be called > from dequeue_signal() which will be from from a different context than > the interrupt context. > I'll be even more explicit. Inside dequeue_signal(), do_schedule_next_timer() is called which then call posix_cpu_tim

Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-25 Thread Olivier Langlois
On Fri, 2013-04-19 at 14:47 +0200, Frederic Weisbecker wrote: > > > > > I might be mistaken but I believe that firing timers are not rescheduled > > in the current interrupt context. They are going to be rescheduled later > > from the task context handling the timer generated signal. > > No, whe

Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-19 Thread Frederic Weisbecker
2013/4/19 Olivier Langlois : > Hi Frederic, >> /* >> @@ -1279,6 +1277,7 @@ void run_posix_cpu_timers(struct task_struct *tsk) >> LIST_HEAD(firing); >> struct k_itimer *timer, *next; >> unsigned long flags; >> + struct signal_struct *sig; >> >> BUG_ON(!irqs_disabled());

Re: [PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-18 Thread Olivier Langlois
Hi Frederic, > /* > @@ -1279,6 +1277,7 @@ void run_posix_cpu_timers(struct task_struct *tsk) > LIST_HEAD(firing); > struct k_itimer *timer, *next; > unsigned long flags; > + struct signal_struct *sig; > > BUG_ON(!irqs_disabled()); > > @@ -1336,6 +1335,10 @@ void run

[PATCH 2/3] posix_timers: Defer per process timer stop after timers processing

2013-04-18 Thread Frederic Weisbecker
When we process the posix cpu timers from the tick, we run through two passes: 1) get the timers that want to fire and walk through the remaining ones in order to set the next expiry time. 2) execute the firing timers and possibly reschedule some of them and thus update the next expiry time again