On Tue, Jun 16, 2020 at 7:30 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jun 16, 2020 at 10:40:04AM +0200, Thomas Gleixner wrote: > > Joel, > > > > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> writes: > > > On Fri, Jun 12, 2020 at 03:55:00PM +0200, Thomas Gleixner wrote: > > >> This is also correct vs. user mode entries in NOHZ full scenarios because > > >> user mode entries bring RCU out of EQS and force the RCU irq nesting state > > > > > > I had to re-read this sentence a couple of times. The 'user mode entries' > > > sounds like 'entry into user mode'. It would be good to reword it to 'IRQ > > > entry in user mode'. > > > > :) > > > > > My knowledge predates the rcu-watching reworks so apologies on the below > > > question but I still didn't fully follow why when the idle task behaves > > > differently from being in user mode. Even with user mode we should have: > > > > > > <user mode> (in EQS) > > > <irq entry> <---------- exits EQS so now rcu is watching > > > <softirq entry in the exit path> > > > <timer tick irq entry> <-- the buggy !watching logic prevents rcu_irq_enter > > > -> report QS since tick thinks it is first level. > > > > > > Is there a subtlety here I'm missing? I checked the RCU code and I did not > > > see anywhere that rcu_user_enter() makes it behave differently. Both > > > rcu_user_enter() and rcu_idle_enter() call rcu_eqs_enter(). > > > > The interrupt hit user mode entry does: > > > > idtentry_enter_cond_rcu() > > if (user_mode(regs)) > > enter_from_user_mode() > > user_exit_irqoff() > > __context_tracking_exit(CONTEXT_USER) > > rcu_user_exit() > > rcu_eqs_exit(1) > > ... > > WRITE_ONCE(rdp->dynticks_nmi_nesting, > > DYNTICK_IRQ_NONIDLE); > > > > i.e. for interrupts which enter from user mode we are not invoking > > rcu_irq_enter() at all. > > > > The return from interrupt path has nothing to do with that because > > that's an entry in kernel mode. > > Hi Thomas, > Ah, IRQ entry in user mode triggers the context-tracking path. Makes sense now, thanks. > > This will help me when I have to propose to get rid of dynticks_nmi_nesting again :) > Propose away, but just keep in mind that horrible architectures like x86 really can nest non-maskable interrupts that hit kernel code more than one deep. --Andy
