On Thu, Jul 18, 2019 at 08:52:52PM -0400, Joel Fernandes wrote: > On Thu, Jul 18, 2019 at 8:40 PM Byungchul Park <byungchul.park@xxxxxxx> wrote: > [snip] > > > - There is a bug in the CPU stopper machinery itself preventing it > > > from scheduling the stopper on Y. Even though Y is not holding up the > > > grace period. > > > > Or any thread on Y is busy with preemption/irq disabled preventing the > > stopper from being scheduled on Y. > > > > Or something is stuck in ttwu() to wake up the stopper on Y due to any > > scheduler locks such as pi_lock or rq->lock or something. > > > > I think what you mentioned can happen easily. > > > > Basically we would need information about preemption/irq disabled > > sections on Y and scheduler's current activity on every cpu at that time. > > I think all that's needed is an NMI backtrace on all CPUs. An ARM we > don't have NMI solutions and only IPI or interrupt based backtrace > works which should at least catch and the preempt disable and softirq > disable cases. True, though people with systems having hundreds of CPUs might not thank you for forcing an NMI backtrace on each of them. Is it possible to NMI only the ones that are holding up the CPU stopper? Thanx, Paul > But yeah I don't see why just the stacks of those CPUs that are > blocking the CPU X would not suffice for the trivial cases where a > piece of misbehaving code disable interrupts / preemption and > prevented the stopper thread from executing. > > May be once the test case is ready (no rush!) , then it will be more > clear what can help. > > J. >
