On Thu, Aug 01, 2024 at 09:48:45PM -0400, Olivier Langlois wrote: > fyi, > > I have found the source!!! > > test_kraken-695 [001] d.h.. 21957.157432: timer_start: > timer=0000000076c6a349 function=mix_interrupt_randomness > expires=4297132992 [timeout=0] bucket_expiry=4297132993 cpu=1 idx=1 > flags=P > test_kraken-695 [001] d.h.. 21964.197366: timer_start: > timer=000000006ea403de function=do_nocb_deferred_wakeup_timer > expires=4297133697 [timeout=1] bucket_expiry=4297133698 cpu=1 idx=2 > flags= > test_kraken-695 [001] d.h.. 21964.197368: timer_start: > timer=0000000076c6a349 function=mix_interrupt_randomness > expires=4297133696 [timeout=0] bucket_expiry=4297133697 cpu=1 idx=1 > flags=P > > enqueue_timer() is calling trigger_dyntick_cpu()... > > the vast majority of these timers are from mix_interrupt_randomness but > there is also the occasional do_nocb_deferred_wakeup_timer... > > every time I see a trace, at the same time, I see the interrupt count > increment... there is possible doubt... > > Now, it is time to find a solution or a workaround but I was so happy > of my discovery that I wanted to share! Very good!!! The do_nocb_deferred_wakeup_timer() is due to call_rcu() being invoked in a context where it might not be safe to do a wakeup(). RCU doesn't have a lot of choice in this situation, so the usual approach is to figure out what is invoking call_rcu() on your nohz_full CPUs and to make it run elsewhere. I don't know what is happening with mix_interrupt_randomness(). Thanx, Paul
