[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170803143801.GE1919@mai>
Date: Thu, 3 Aug 2017 16:38:01 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, john.stultz@...aro.org,
linux-kernel@...r.kernel.org, Pratyush Anand <panand@...hat.com>
Subject: Re: RCU stall when using function_graph
On Thu, Aug 03, 2017 at 05:44:21AM -0700, Paul E. McKenney wrote:
[ ... ]
> > > BTW, function_graph tracer is the most invasive of the tracers. It's 4x
> > > slower than function tracer. I'm wondering if the tracer isn't the
> > > cause, but just slows things down enough to cause a some other race
> > > condition that triggers the bug.
> >
> > Yes, that could be true.
> >
> > I tried the following scenario:
> >
> > - cpufreq governor => userspace + max_freq (1.2GHz)
> > - function_graph set ==> OK
> >
> > - cpufreq governor => userspace + min_freq (200MHz)
> > - function_graph set ==> RCU stall
> >
> > Beside that, I realize the board is constantly processing SOF interrupts
> > every 124us, so that adds more overhead.
> >
> > Removing the USB support, thus the associated processing for the SOF
> > interrupts, I don't see anymore the RCU stall.
>
> Looks like Steve called this one! ;-)
Yep :)
> > Is it the expected behavior to have the system hang after a RCU stall
> > raises ?
>
> No, but if NMI stack traces are enabled and there are any NMI problems,
> bad things can happen. In addition, the bulk of output can cause problems
> if you have a slow console connection.
Ok, thanks.
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists