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
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
On Thu, Mar 17, 2016 at 06:41:42PM -0400, Chris Metcalf wrote:
> The build bot caught the fact that I missed arch/xtensa since it doesn't use
> LOCK_TEXT, so if you're testing on that (ok maybe unlikely) you can add this:
Ha!, no. regular boring x86_64.
On Thu, Mar 17, 2016 at 06:41:42PM -0400, Chris Metcalf wrote:
> The build bot caught the fact that I missed arch/xtensa since it doesn't use
> LOCK_TEXT, so if you're testing on that (ok maybe unlikely) you can add this:
Ha!, no. regular boring x86_64.
On 3/17/2016 3:36 PM, Peter Zijlstra wrote:
On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
Currently you can only request a backtrace of either all cpus, or
all cpus but yourself. It can also be helpful to request a remote
backtrace of a single cpu, and since we want that, the
On 3/17/2016 3:36 PM, Peter Zijlstra wrote:
On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
Currently you can only request a backtrace of either all cpus, or
all cpus but yourself. It can also be helpful to request a remote
backtrace of a single cpu, and since we want that, the
On Thu, Mar 17, 2016 at 03:55:57PM -0700, Paul E. McKenney wrote:
> The RCU stall-warn stack traces can be ugly, agreed.
Ugly isn't the problem, completely random bollocks that puts you on the
wrong path was more the problem.
It uses a stack pointer saved at some random time in the past to start
On Thu, Mar 17, 2016 at 03:55:57PM -0700, Paul E. McKenney wrote:
> The RCU stall-warn stack traces can be ugly, agreed.
Ugly isn't the problem, completely random bollocks that puts you on the
wrong path was more the problem.
It uses a stack pointer saved at some random time in the past to start
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
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
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
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
On Thu, Mar 17, 2016 at 03:55:57PM -0700, Paul E. McKenney wrote:
> 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,
On Thu, Mar 17, 2016 at 03:55:57PM -0700, Paul E. McKenney wrote:
> 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,
On Fri, Mar 18, 2016 at 12:11:28AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 03:55:57PM -0700, Paul E. McKenney wrote:
> > The RCU stall-warn stack traces can be ugly, agreed.
>
> Ugly isn't the problem, completely random bollocks that puts you on the
> wrong path was more the
On Fri, Mar 18, 2016 at 12:11:28AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 17, 2016 at 03:55:57PM -0700, Paul E. McKenney wrote:
> > The RCU stall-warn stack traces can be ugly, agreed.
>
> Ugly isn't the problem, completely random bollocks that puts you on the
> wrong path was more the
On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
> Currently you can only request a backtrace of either all cpus, or
> all cpus but yourself. It can also be helpful to request a remote
> backtrace of a single cpu, and since we want that, the logical
> extension is to support a
On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
> Currently you can only request a backtrace of either all cpus, or
> all cpus but yourself. It can also be helpful to request a remote
> backtrace of a single cpu, and since we want that, the logical
> extension is to support a
Currently you can only request a backtrace of either all cpus, or
all cpus but yourself. It can also be helpful to request a remote
backtrace of a single cpu, and since we want that, the logical
extension is to support a cpumask as the underlying primitive.
This change modifies the existing
Currently you can only request a backtrace of either all cpus, or
all cpus but yourself. It can also be helpful to request a remote
backtrace of a single cpu, and since we want that, the logical
extension is to support a cpumask as the underlying primitive.
This change modifies the existing
On Thu, Mar 17, 2016 at 06:31:44PM -0400, Chris Metcalf wrote:
> On 3/17/2016 3:36 PM, Peter Zijlstra wrote:
> >On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
> >>Currently you can only request a backtrace of either all cpus, or
> >>all cpus but yourself. It can also be helpful to
On Thu, Mar 17, 2016 at 06:31:44PM -0400, Chris Metcalf wrote:
> On 3/17/2016 3:36 PM, Peter Zijlstra wrote:
> >On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
> >>Currently you can only request a backtrace of either all cpus, or
> >>all cpus but yourself. It can also be helpful to
On 3/17/2016 6:38 PM, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 06:31:44PM -0400, Chris Metcalf wrote:
On 3/17/2016 3:36 PM, Peter Zijlstra wrote:
On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
Currently you can only request a backtrace of either all cpus, or
all cpus but
On 3/17/2016 6:38 PM, Peter Zijlstra wrote:
On Thu, Mar 17, 2016 at 06:31:44PM -0400, Chris Metcalf wrote:
On 3/17/2016 3:36 PM, Peter Zijlstra wrote:
On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
Currently you can only request a backtrace of either all cpus, or
all cpus but
On Thu, Mar 17, 2016 at 08:36:00PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
> > Currently you can only request a backtrace of either all cpus, or
> > all cpus but yourself. It can also be helpful to request a remote
> > backtrace of a single
On Thu, Mar 17, 2016 at 08:36:00PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 16, 2016 at 01:02:10PM -0400, Chris Metcalf wrote:
> > Currently you can only request a backtrace of either all cpus, or
> > all cpus but yourself. It can also be helpful to request a remote
> > backtrace of a single
On Fri, Mar 18, 2016 at 09:40:25AM +, 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.
> >>>
>
On Fri, Mar 18, 2016 at 09:40:25AM +, 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.
> >>>
>
28 matches
Mail list logo
