Re: [PATCH 2/2] arm: make return_address available for ARM_UNWIND
From: Steven Rostedt
Date: Thu Jan 03 2013 - 11:58:50 EST
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:
> 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 :-)
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:
Heck, the user could just keep those from being traced by doing:
echo kernel_text_address core_kernel_text search_index > \
If DYNAMIC_FTRACE is defined.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/