On Thu, 2024-08-01 at 20:01 -0700, Paul E. McKenney wrote: > > 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 there few more that are popping out like: tsc_sync_check_timer_fn mce_timer_fn but those 2 + do_nocb_deferred_wakeup_timer are not immediately generating an interrupt. Only mix_interrupt_randomness does because it adds an already timed out timer. So the CPU is kicked on insertion. I have quickly looked at drivers/char/random.c and there is no obvious way to address this that I can think of without causing potential serious side-effects... but I really find mysterious that only 1 of my nohz_full cpus is impacted this... and imho, this does not sound like a good idea to include interrupt randomness of a nohz_full cpu... I think that I am going to throw down the towel of reaching the goal of 100% interrupt free for now. The amount of efforts required to reach the goal vs the diminishing result I can get is not a good deal. For now, I am going to tolerate this 27uSec interrupt once every 2-3 seconds... but I find this challenge very fascinating and I'll start to follow Brendan Gregg's blog to learn more about the field. thank you very much for your assistance. I am leaving with an impression that the rcu dev list is very helpful and friendly!
