RE: [RFC] [PATCH] Performance of del_timer_sync
From: Chen, Kenneth W
Date: Tue May 11 2004 - 15:31:51 EST
>>>>> Andrew Morton wrote on Tuesday, May 11, 2004 1:12 PM
> > > Ingo, why is this not sufficient?
> > it's not sufficient because a timer might be running on another CPU even
> > if it has not been deleted. We delete a timer prior running it (so that
> > the timer fn can re-activate the timer). So del_timer_sync() has to
> > synchronize independently of whether the timer was removed or not.
> Ah, OK, the timer handler may re-add itself. Really, that's a bug in the
> caller: once they've decided to shoot down the timer the caller should have
> made state changes which prevent the handler from re-adding the timer.
> Still, too late to change that.
> Neither AIO nor schedule_timeout() actually re-add the timer so they don't
> need the full treatment, yes?
> diff -puN kernel/timer.c~del-timer-speedup kernel/timer.c
> --- 25/kernel/timer.c~del-timer-speedup 2004-05-11 13:05:41.997859088 -0700
> +++ 25-akpm/kernel/timer.c 2004-05-11 13:07:32.493061264 -0700
> @@ -348,8 +348,13 @@ del_again:
> return ret;
> +int del_single_shot_timer(struct timer_struct *timer)
> + if (del_timer(timer))
> + del_timer_sync(timer);
I'm confused, isn't the polarity of del_timer() need to be reversed?
Also propagate the return value of del_timer_sync()?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/