Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752559AbdHIN2K (ORCPT ); Wed, 9 Aug 2017 09:28:10 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:38486 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbdHIN2J (ORCPT ); Wed, 9 Aug 2017 09:28:09 -0400 Subject: Re: RCU stall when using function_graph To: paulmck@linux.vnet.ibm.com, Pratyush Anand Cc: =?UTF-8?B?6rmA64+Z7ZiE?= , john.stultz@linaro.org, Steven Rostedt , linux-kernel@vger.kernel.org References: <20170802124239.GD1919@mai> <20170802090744.6922e9e9@gandalf.local.home> <11d179df-d8a9-5d3e-3bc4-080df464e85d@linaro.org> <20170803124421.GP3730@linux.vnet.ibm.com> <20170803143801.GE1919@mai> <20170806170220.GQ3730@linux.vnet.ibm.com> <20170809125804.GT3730@linux.vnet.ibm.com> From: Daniel Lezcano Message-ID: Date: Wed, 9 Aug 2017 15:28:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170809125804.GT3730@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2601 Lines: 69 On 09/08/2017 14:58, Paul E. McKenney wrote: > On Wed, Aug 09, 2017 at 02:43:49PM +0530, Pratyush Anand wrote: >> >> >> On Sunday 06 August 2017 10:32 PM, Paul E. McKenney wrote: >>> On Sat, Aug 05, 2017 at 02:24:21PM +0900, κΉ€λ™ν˜„ wrote: >>>> Dear All >>>> >>>> As for me, after configuring function_graph as below, crash disappears. >>>> "echo 0 > d/tracing/tracing_on" >>>> "sleep 1" >>>> >>>> "echo function_graph > d/tracing/current_tracer" >>>> "sleep 1" >>>> >>>> "echo smp_call_function_single > d/tracing/set_ftrace_filter" >> >> It will limit trace output to only for the filtered function >> (smp_call_function_single). >> >>>> adb shell "sleep 1" >>>> >>>> "echo 1 > d/tracing/tracing_on" >>>> adb shell "sleep 1" >>>> >>>> Right after function_graph is enabled, too many logs are traced upon IRQ >>>> transaction which many times eventually causes stall. >>> >>> That would do it! >>> >>> Hmmm... >>> >>> Steven, would it be helpful if RCU were to inform tracing (say) halfway >>> through the RCU CPU stall interval, allowing the tracer to do something >>> like cond_resched_rcu_qs()? I can imagine all sorts of reasons why this >>> wouldn't work, for example, if all the tracing was with irqs disabled >>> or some such, but figured I should ask. >>> >>> Does Guillermo's approach work for others? >> >> Limited output with a couple of filtered function will definitely >> not cause RCU schedule stall. But the question is whether we should >> expect a full function graph trace working on every platform or not >> (specially the one which generates high interrupts)? > > It might well be that the user must disable RCU CPU stall warnings via > the rcu_cpu_stall_suppress sysfs entry (or increase their timeout via th > rcu_cpu_stall_timeout sysfs entry) before doing something that greatly > increases overhead. Like enabling large quantities of tracing. ;-) > > It -might- be possible to do this automatically, but reliable > automation would require that tracing understand how often each > function was called, which sounds to me to be a bit of a stretch. > > Thoughts? A random thought: Is it possible to have a mid-timeout happening and store some information like the instruction pointer, so when the timeout happen we can compare if there was some progress, if yes, very likely, system performance collapsed and we are not fast enough. -- Linaro.org β”‚ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog