On Fri, Jan 4, 2013 at 1:58 AM, Steven Rostedt <rost...@goodmis.org> wrote: > On Thu, 2013-01-03 at 16:23 +0000, Russell King - ARM Linux wrote: >> On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote: >> > On Thu, 2013-01-03 at 14:13 +0000, Russell King - ARM Linux wrote: >> > > In summary, from what I can see in the patch, the reason why the ifdefs >> > > are the way they are, and the reason the warning is there has not been >> > > addressed; these patches just seem to be aimed just at removing a >> > > #warning >> > > statement to make the warning go away. >> > >> > You're correct that this patch does not solve any of theses issues. Now, >> > I'm thinking that ftrace has matured where these issues don't exist, and >> > where they do, it will only cause noise in the trace than anything >> > serious. But, this needs to be looked deeper to make sure. >> >> Looking back in the archives, it seems that we had a problem with ftrace >> and the unwinder polluting the trace information: >> >> http://lists.arm.linux.org.uk/lurker/message/20090604.201745.1c41ee6c.en.html >> >> There's quite a bit of discussion in that thread about this which details >> why we came up with what we have today. > > Thanks for the link. In fact, I see I was even involved :-) > > http://lists.arm.linux.org.uk/lurker/message/20090609.213448.b4e4d096.en.html > > Just as I explained, the problem isn't a recursion bug, but just noise > in the trace. > > Some of what is called by unwind_frame() will always be traced, and I > wouldn't want 'notrace' annotation on those. > > If anything, I would just suggest another config option that lets the > user decide if they don't mind the messiness of the trace for the added > benefit of where the latency output came from. > > Also, it's rather trivial to make the entire unwind.c not traced, by > adding in the Makefile: > > CFLAGS_REMOVE_unwind.o = -pg > > But that only stops the tracing of the unwind_*. Looks to be a lot of > those. But it wont stop the tracing of: > > kernel_text_address <-unwind_frame > core_kernel_text <-unwind_frame > search_index <-unwind_frame > etc. > > Heck, the user could just keep those from being traced by doing: > > echo kernel_text_address core_kernel_text search_index > \ > /sys/kernel/debug/tracing/set_ftrace_notrace > > If DYNAMIC_FTRACE is defined. > > -- Steve > >
With "CFLAGS_REMOVE_unwind.o = -pg" and with CONFIG_PROVE_LOCKING turned on, I confirmed that there's no trace output like Steve mentioned. However, if I turn off CONFIG_PROVE_LOCKING, "irqsoff" and "preemptirqsoff" ftracer prints these lines : kernel_text_address <-unwind_frame core_kernel_text <-unwind_frame search_index <-unwind_frame While I investigated the reason, I just found out there's two function with same name, trace_hardirqs_off. One in kernel/trace/trace_irqsoff.c and another in kernel/lockdep.c. And both symbols are exported. I am wondering whether it is intentionally maintained code to manipulate ftrace and lockdep or not. I guess it's probably not. -- Kpark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/