Re: [patch 01/12] clockevents: Prevent timer interrupt starvation

[Peter Zijlstra]

On Tue, Apr 07, 2026 at 01:30:42PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 07 2026 at 11:42, Peter Zijlstra wrote:
> > On Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:
> >> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
> >>  		return dev->set_next_ktime(expires, dev);
> >>  
> >>  	delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
> >>  
> >> +	if (delta > (int64_t)dev->min_delta_ns) {
> >> +		delta = min(delta, (int64_t) dev->max_delta_ns);
> >> +		clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
> >> +		if (!dev->set_next_event((unsigned long) clc, dev))
> >> +			return 0;
> >> +	}
> >>  
> >> +	if (dev->next_event_forced)
> >> +		return 0;
> >>  
> >> +	if (dev->set_next_event(dev->min_delta_ticks, dev)) {
> >> +		if (!force || clockevents_program_min_delta(dev))
> >> +			return -ETIME;
> >> +	}
> >> +	dev->next_event_forced = 1;
> >> +	return 0;
> >>  }
> >
> > Looking at the implementation of clockevents_program_min_delta() doing
> > that dev->set_next_event(dev->min_delta_ticks,) right before it seems a
> > bit daft.
> >
> > But yes, this is effectively also what the old code did.
> 
> yes. I looked at that and didn't come up with a good plan.
> 
> > The only thing that seems to be different, is that the old code would
> > return the ->set_next_event() error code, rather than 0 in the !force
> > case.
> 
> You mean when dev->next_event_forced is set and the set_event() callback
> above failed?

next_event_foced = 0;
force = 0;

Then the old code would return rc (return value of ->set_next_event),
while the new code will return -ETIME.

(not 0 like I said).

I suppose ->set_next_event() will only ever fail with -ETIME?