On Fri, Aug 02, 2024 at 09:46:03AM -0400, Olivier Langlois wrote: > 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! Are you doing system calls on your worker CPUs? If so, one straightforward way to get rid of this is to make your application push the system calls off to the housekeeping CPU. Keep in mind that system calls often need to defer work of one sort or another. The real-time guys would know more about this sort of thing. Thanx, Paul
