RE: [RFC] [PATCH] Performance of del_timer_sync

[Chen, Kenneth W]

>>>>> 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;
>  }
> -
>  EXPORT_SYMBOL(del_timer_sync);
> +
> +int del_single_shot_timer(struct timer_struct *timer)
> +{
> +	if (del_timer(timer))
> +		del_timer_sync(timer);
> +}
>  #endif

I'm confused, isn't the polarity of del_timer() need to be reversed?
Also propagate the return value of del_timer_sync()?

- Ken


-
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/