Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752530AbYJWQZw (ORCPT ); Thu, 23 Oct 2008 12:25:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754473AbYJWQZj (ORCPT ); Thu, 23 Oct 2008 12:25:39 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:33407 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754327AbYJWQZi (ORCPT ); Thu, 23 Oct 2008 12:25:38 -0400 Date: Thu, 23 Oct 2008 12:05:53 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Jan Kiszka cc: linux-kernel@vger.kernel.org, Ingo Molnar , Frederic Weisbecker , Abhishek Sagar , "David S. Miller" , Thomas Gleixner , Peter Zijlstra , Andrew Morton , Linus Torvalds , Steven Rostedt Subject: Re: [PATCH 08/13 v2] ftrace: do not trace init sections In-Reply-To: <49008A9B.8040905@siemens.com> Message-ID: References: <20081022212721.167005680@goodmis.org> <20081022213552.440512191@goodmis.org> <49005CD0.2070807@siemens.com> <49008A9B.8040905@siemens.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1632 Lines: 36 On Thu, 23 Oct 2008, Jan Kiszka wrote: > > >From my POV - I'm using mcount tracing for a few years now -, the thing > about this is gaining a complete overview of what happens at function > level, which code paths were taken (at that level). Each bit of > information you (have to) drop can harm here, even more if they come in > larger chunks like in this case. Then you should be happy :-) I removed the notrace to those sections. Although there is already a notrace on the __init. We probably should remove it. The recordmcount.pl does not add tracing to these functions. If you want tracing of these functions, you will need to use the static ftrace tracer (!DYNAMIC_FTRACE) > > I don't know if this feature is already considered for / part of > mainline, but oops backtraces based on mcount instrumentation used to be > quite helpful for me to understand the wider context of several faults. > The more you have to mask out of this picture, the harder it gets to > match the trace to your model of the kernel activities. At least you > have to know more in advance about the limitation of the tracer... The ftrace buffer can be dumped out on oops. I'm not sure if it is always on. If it is, I need to make it default off and add a command line and sysctl to turn it on. Otherwise, we will have people complaining about the extra output to the console on oops. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/