Re: [PATCH 1/3] hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le Thu, Dec 19, 2024 at 10:00:12PM +0300, Usama Arif a écrit :
> > @@ -1240,6 +1280,12 @@ static int __hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim,
> >  
> >  	hrtimer_set_expires_range_ns(timer, tim, delta_ns);
> >  
> > +	if (unlikely(!this_cpu_base->online)) {
> > +		enqueue_hrtimer_offline(timer, base, mode);
> 
> Thanks for the fix!
> 
> It looks good to me, maybe as a follow up, we could rename switch_hrtimer_base to 
> enqueue_hrtimer_local? (or maybe something more appropriate)
> There are now 2 different paths that switch hrtimer base (enqueue_hrtimer_offline and
> switch_hrtimer_base).

I considered extending switch_hrtimer_base() instead to handle offline
CPU from there but that turned out ugly since what follows assumes to either
queue locally and possibly reprogram or queue remotely and not reprogram.

enqueue_hrtimer_global() does only enqueue remotely and possibly
trigger a reprogram.

And indeed we could move switch_hrtimer_base() + enqueue_hrtimer() +
hrtimer_force_reprogram() to a enqueue_hrtimer_online() for example.

Perhaps that would clarify things a bit, I don't know...

Thanks.

> 
> > +		return 0;
> > +	}
> > +
> > +
> nit: extra new line above.
> >  	/* Switch the timer base, if necessary: */
> >  	if (!force_local) {
> >  		new_base = switch_hrtimer_base(timer, base,
> 




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux