Messages in this thread | | | Date | Mon, 28 Nov 2022 17:20:10 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH v4 14/16] timer: Implement the hierarchical pull model |
| |
On Thu, Nov 24, 2022 at 08:47:56AM +0100, Anna-Maria Behnsen wrote: > On Tue, 15 Nov 2022, Frederic Weisbecker wrote: > > > On Fri, Nov 04, 2022 at 03:57:35PM +0100, Anna-Maria Behnsen wrote: > > > +static int tmigr_cpu_offline(unsigned int cpu) > > > +{ > > > + struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu); > > > + > > > + raw_spin_lock_irq(&tmc->lock); > > > + tmc->online = 0; > > > + __tmigr_cpu_deactivate(tmc, KTIME_MAX); > > > > This means that if the CPU is going idle for some time during > > the hotplug process (ie: at some point between CPUHP_AP_TMIGR_ONLINE > > and CPUHP_TEARDOWN_CPU), then a global timer may be delayed for that long. > > > > I guess it shouldn't be too bad but worth mentioning... > > > > Although if it happens to be a problem it could be solved with simply allowing > > tmigr_cpu_deactivate() when !tmc->online. > > The plan was (and I broke it) to let the CPU handle global timers by itself > as long as timer migration hierarchy is not completely initialized and as > long as CPU is marked offline in timer migration hierarchy. Otherwise > global timers might be delayed during this period. The proper way would be > that tmigr_cpu_deactivate(nextexp) directly returns nextexp if !tmc->online > and tmigr hierarchy is not in place yet. I will have a deeper look if there > was a reason why I changed the return to KTIME_MAX...
Well, do you need tmc->online at all?
I guess tmigr_cpu_offline() could be simply removed because when the CPU goes finally down in do_idle() it does:
tick_nohz_idle_stop_tick(); cpuhp_report_idle_dead();
So the tick is expected to be stopped (better check it is) and thus the tmc should be deactivated.
I guess you just need to call tmigr_cpu_activate() from timers_prepare_cpu().
Or am I missing something along the way?
| |