Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1360279

Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

From "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods
Date 2016-03-18 01:50 +0100
Message-ID <rdQM2-6vV-5@gated-at.bofh.it> (permalink)
References <rdLW2-35m-9@gated-at.bofh.it> <rdLW2-35m-11@gated-at.bofh.it> <rdLW2-35m-7@gated-at.bofh.it> <rdP3B-5d9-35@gated-at.bofh.it> <rdQj0-6jm-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Mar 17, 2016 at 08:17:59PM -0400, Chris Metcalf wrote:
> On 3/17/2016 6:55 PM, Paul E. McKenney wrote:
> >The RCU stall-warn stack traces can be ugly, agreed.
> >
> >That said, RCU used to use NMI-based stack traces, but switched to the
> >current scheme due to the NMIs having the unfortunate habit of locking
> >things up, which IIRC often meant no stack traces at all.  If I recall
> >correctly, one of the problems was self-deadlock in printk().
> 
> Steven Rostedt enabled the per_cpu printk func support in June 2014, and
> the nmi_backtrace code uses it to just capture printk output to percpu
> buffers, so I think it's going to be a lot more robust than earlier attempts.

That would be a very good thing, give or take the "I think" qualifier.
And assuming that the target CPU is healthy enough to find its way back
to some place that can dump the per-CPU printk buffer.  I might well
be overly paranoid, but I have to suspect that the probability of that
buffer getting dumped is reduced greatly on a CPU that isn't healthy
enough to respond to RCU, though.

But it seems like enabling the experiment might be useful.

"Try enabling the NMI version.  If that doesn't get you your RCU CPU
stall warning stack trace, try the remote-print variant."

Or I suppose we could just do both in succession, just in case their
console was a serial port.  ;-)

							Thanx, Paul

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Peter Zijlstra <peterz@infradead.org> - 2016-03-17 20:40 +0100
  Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Chris Metcalf <cmetcalf@mellanox.com> - 2016-03-17 23:40 +0100
    Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Peter Zijlstra <peterz@infradead.org> - 2016-03-17 23:40 +0100
      Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Peter Zijlstra <peterz@infradead.org> - 2016-03-18 00:20 +0100
  Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-18 00:00 +0100
    Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Peter Zijlstra <peterz@infradead.org> - 2016-03-18 00:10 +0100
    Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Peter Zijlstra <peterz@infradead.org> - 2016-03-18 00:20 +0100
      Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-18 01:40 +0100
    Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Chris Metcalf <cmetcalf@mellanox.com> - 2016-03-18 01:20 +0100
      Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-18 01:50 +0100
        Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods Daniel Thompson <daniel.thompson@linaro.org> - 2016-03-18 10:50 +0100
          Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace()  methods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-19 01:00 +0100

csiph-web