Messages in this thread | | | Date | Mon, 5 Jun 2023 16:26:33 +0200 | From | Frederic Weisbecker <> | Subject | Re: [patch 18/20] posix-timers: Clarify posix_timer_fn() comments |
| |
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>
| |