From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Daniel Thompson <daniel.thompson@linaro.org> Cc: Chris Metcalf <cmetcalf@mellanox.com>, Peter Zijlstra <peterz@infradead.org>, Russell King <linux@arm.linux.org.uk>, Thomas Gleixner <tglx@linutronix.de>, Aaron Tomlin <atomlin@redhat.com>, Ingo Molnar <mingo@redhat.com>, Andrew Morton <akpm@osdl.org>, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Date: Fri, 18 Mar 2016 16:54:45 -0700 [thread overview] Message-ID: <20160318235445.GG4287@linux.vnet.ibm.com> (raw) In-Reply-To: <56EBCD09.2000400@linaro.org> On Fri, Mar 18, 2016 at 09:40:25AM +0000, Daniel Thompson wrote: > On 18/03/16 00:33, Paul E. McKenney wrote: > >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. > > The target CPU doesn't dump the buffer. It "just" fields the NMI, > stores the backtrace and sets a flag. > > The buffer is dumped to console by the requesting CPU, either when > all backtraces have come back or when a timeout is reached. That does sound a bit more robust, good! > >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. ;-) > > I guess both might be needed but only when the target CPU is dead > enough to fail to respond to NMI. In principle, we could exploit the > timeout in the NMI backtrace logic and only issue the missing > backtraces. It would be really nice if I could call one function that used the best strategy for getting information (including stack trace) about a specified CPU. Ditto for getting information about a specified task, which might be running or might be preempted at the time. Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: paulmck@linux.vnet.ibm.com (Paul E. McKenney) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Date: Fri, 18 Mar 2016 16:54:45 -0700 [thread overview] Message-ID: <20160318235445.GG4287@linux.vnet.ibm.com> (raw) In-Reply-To: <56EBCD09.2000400@linaro.org> On Fri, Mar 18, 2016 at 09:40:25AM +0000, Daniel Thompson wrote: > On 18/03/16 00:33, Paul E. McKenney wrote: > >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. > > The target CPU doesn't dump the buffer. It "just" fields the NMI, > stores the backtrace and sets a flag. > > The buffer is dumped to console by the requesting CPU, either when > all backtraces have come back or when a timeout is reached. That does sound a bit more robust, good! > >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. ;-) > > I guess both might be needed but only when the target CPU is dead > enough to fail to respond to NMI. In principle, we could exploit the > timeout in the NMI backtrace logic and only issue the missing > backtraces. It would be really nice if I could call one function that used the best strategy for getting information (including stack trace) about a specified CPU. Ditto for getting information about a specified task, which might be running or might be preempted at the time. Thanx, Paul
next prev parent reply other threads:[~2016-03-18 23:54 UTC|newest] Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-29 21:40 [PATCH 0/4] improvements to the nmi_backtrace code Chris Metcalf 2016-02-29 21:40 ` Chris Metcalf 2016-02-29 21:40 ` [PATCH 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf 2016-02-29 21:40 ` Chris Metcalf 2016-02-29 21:40 ` [PATCH 2/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf 2016-03-01 14:23 ` Daniel Thompson 2016-03-01 16:01 ` Chris Metcalf 2016-03-07 8:26 ` Daniel Thompson 2016-03-07 17:05 ` Chris Metcalf 2016-03-07 9:48 ` Peter Zijlstra 2016-03-07 17:38 ` Chris Metcalf 2016-03-07 20:43 ` Peter Zijlstra 2016-03-16 17:02 ` [PATCH v2 0/4] improvements to the nmi_backtrace code Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-16 17:02 ` [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-17 19:36 ` Peter Zijlstra 2016-03-17 19:36 ` Peter Zijlstra 2016-03-17 22:31 ` Chris Metcalf 2016-03-17 22:31 ` Chris Metcalf 2016-03-17 22:38 ` Peter Zijlstra 2016-03-17 22:38 ` Peter Zijlstra 2016-03-17 22:41 ` Chris Metcalf 2016-03-17 22:41 ` Chris Metcalf 2016-03-17 23:14 ` Peter Zijlstra 2016-03-17 23:14 ` Peter Zijlstra 2016-03-17 22:55 ` Paul E. McKenney 2016-03-17 22:55 ` Paul E. McKenney 2016-03-17 23:09 ` Peter Zijlstra 2016-03-17 23:09 ` Peter Zijlstra 2016-03-17 23:11 ` Peter Zijlstra 2016-03-17 23:11 ` Peter Zijlstra 2016-03-18 0:28 ` Paul E. McKenney 2016-03-18 0:28 ` Paul E. McKenney 2016-03-18 0:17 ` Chris Metcalf 2016-03-18 0:17 ` Chris Metcalf 2016-03-18 0:33 ` Paul E. McKenney 2016-03-18 0:33 ` Paul E. McKenney 2016-03-18 9:40 ` Daniel Thompson 2016-03-18 9:40 ` Daniel Thompson 2016-03-18 23:54 ` Paul E. McKenney [this message] 2016-03-18 23:54 ` Paul E. McKenney 2016-03-16 17:02 ` [PATCH v2 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-16 17:02 ` [PATCH v2 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf 2016-03-16 17:02 ` [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-16 17:02 ` Chris Metcalf 2016-03-16 18:46 ` kbuild test robot 2016-03-16 18:46 ` kbuild test robot 2016-03-16 18:46 ` kbuild test robot 2016-03-16 18:46 ` kbuild test robot 2016-03-21 15:38 ` Peter Zijlstra 2016-03-21 15:38 ` Peter Zijlstra 2016-03-21 15:38 ` Peter Zijlstra 2016-03-21 15:46 ` Chris Metcalf 2016-03-21 15:46 ` Chris Metcalf 2016-03-21 15:46 ` Chris Metcalf 2016-03-21 15:46 ` Chris Metcalf 2016-03-21 15:42 ` Peter Zijlstra 2016-03-21 15:42 ` Peter Zijlstra 2016-03-21 16:15 ` Chris Metcalf 2016-03-21 16:15 ` Chris Metcalf 2016-03-21 16:15 ` Chris Metcalf 2016-03-21 16:32 ` Peter Zijlstra 2016-03-21 16:32 ` Peter Zijlstra 2016-03-21 17:12 ` Chris Metcalf 2016-03-21 17:12 ` Chris Metcalf 2016-03-21 17:12 ` Chris Metcalf 2016-03-21 17:12 ` Chris Metcalf 2016-03-21 17:17 ` Peter Zijlstra 2016-03-21 17:17 ` Peter Zijlstra 2016-03-21 16:48 ` Peter Zijlstra 2016-03-21 16:48 ` Peter Zijlstra 2016-03-21 21:49 ` Peter Zijlstra 2016-03-21 21:49 ` Peter Zijlstra 2016-03-22 17:19 ` [PATCH v3 0/4] improvements to the nmi_backtrace code Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:19 ` [PATCH v3 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:19 ` [PATCH v3 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:19 ` [PATCH v3 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf 2016-03-22 17:19 ` [PATCH v3 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:19 ` Chris Metcalf 2016-03-22 17:30 ` Peter Zijlstra 2016-03-22 17:30 ` Peter Zijlstra 2016-03-22 22:28 ` Rafael J. Wysocki 2016-03-22 22:28 ` Rafael J. Wysocki 2016-03-22 22:31 ` Rafael J. Wysocki 2016-03-22 22:31 ` Rafael J. Wysocki 2016-03-22 22:45 ` Peter Zijlstra 2016-03-22 22:45 ` Peter Zijlstra 2016-03-23 0:50 ` Rafael J. Wysocki 2016-03-23 0:50 ` Rafael J. Wysocki 2016-03-23 7:53 ` Peter Zijlstra 2016-03-23 7:53 ` Peter Zijlstra 2016-03-30 17:16 ` [PATCH v4 0/4] improvements to the nmi_backtrace code Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-03-30 17:16 ` [PATCH v4 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-03-30 17:16 ` [PATCH v4 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-03-30 17:16 ` [PATCH v4 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf 2016-03-30 17:16 ` [PATCH v4 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-03-30 17:16 ` Chris Metcalf 2016-02-29 21:40 ` [PATCH 3/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf 2016-02-29 21:40 ` Chris Metcalf 2016-02-29 21:40 ` [PATCH 4/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf 2016-03-01 0:49 ` [PATCH 0/4] improvements to the nmi_backtrace code Andrew Morton 2016-03-01 0:49 ` Andrew Morton 2016-03-01 10:01 ` Petr Mladek 2016-03-01 10:01 ` Petr Mladek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160318235445.GG4287@linux.vnet.ibm.com \ --to=paulmck@linux.vnet.ibm.com \ --cc=akpm@osdl.org \ --cc=atomlin@redhat.com \ --cc=cmetcalf@mellanox.com \ --cc=daniel.thompson@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.