On Tue, Sep 20, 2022 at 03:26:28PM +0800, Pingfan Liu wrote: > On Fri, Sep 16, 2022 at 03:42:58PM +0200, Frederic Weisbecker wrote: > > Note this is only locking the rdp's node, not the root node. > > Therefore if CPU 0 and CPU 256 are going off at the same time and they > > don't belong to the same node, the above won't protect against concurrent > > TICK_DEP_BIT_RCU set/clear. > > > > Nice, thanks for the careful thoughts. How about moving the counting > place to the root node? You could but then you'd need to lock the root node. > > > My suspicion is that we don't need this TICK_DEP_BIT_RCU tick dependency > > anymore. I believe it was there because of issues that were fixed with: > > > > 53e87e3cdc15 (timers/nohz: Last resort update jiffies on nohz_full IRQ entry) > > and: > > > > a1ff03cd6fb9 (tick: Detect and fix jiffies update stall) > > > > It's unfortunately just suspicion because the reason for that tick dependency > > is unclear but I believe it should be safe to remove now. > > > > I have gone through this tick dependency again, but got less. > > I think at least from the RCU's viewpoint, it is useless since > multi_cpu_stop()->rcu_momentary_dyntick_idle() has eliminate the > requirement for tick interrupt. Partly yes. > Is there a way to have a convincing test so that these code can be removed? > Or this code will be got along with? Hmm, Paul might remember which rcutorture scenario would trigger it?
