Re: [patch 18/20] posix-timers: Clarify posix_timer_fn() comments

Frederic Weisbecker
2023-06-05T14:26:41Z

Le Thu, Jun 01, 2023 at 09:07:37PM +0200, Thomas Gleixner a écrit :
> @@ -359,34 +360,35 @@ static enum hrtimer_restart posix_timer_
> * FIXME: What we really want, is to stop this
> * timer completely and restart it in case the
> * SIG_IGN is removed. This is a non trivial
> - * change which involves sighand locking
> - * (sigh !), which we don't want to do late in
> - * the release cycle.
> + * change to the signal handling code.
> + *
> + * For now let timers with an interval less than a
> + * jiffie expire every jiffie and recheck for a
> + * valid signal handler.
> + *
> + * This avoids interrupt starvation in case of a
> + * very small interval, which would expire the
> + * timer immediately again.
> *
> - * For now we just let timers with an interval
> - * less than a jiffie expire every jiffie to
> - * avoid softirq starvation in case of SIG_IGN
> - * and a very small interval, which would put
> - * the timer right back on the softirq pending
> - * list. By moving now ahead of time we trick
> - * hrtimer_forward() to expire the timer
> - * later, while we still maintain the overrun
> - * accuracy, but have some inconsistency in
> - * the timer_gettime() case. This is at least
> - * better than a starved softirq. A more
> - * complex fix which solves also another related
> - * inconsistency is already in the pipeline.
> + * Moving now ahead of time by one jiffie tricks
> + * hrtimer_forward() to expire the timer later,
> + * while it still maintains the overrun accuracy
> + * for the price of a slight inconsistency in the
> + * timer_gettime() case. This is at least better
> + * than a starved softirq.

Could be hardirq. How about:

"This is at least better than a timer storm."

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>