The recordmcount script is now robust enough not to process any sections
but the .text section. But the gcc compiler still adds a call to mcount.
Note: The function mcount looks like:
ENTRY(mcount)
ret
END(mcount)
Which means the overhead is just a return.
This patch adds notrace to the init sections to not even bother calling
mcount (which simply returns).
Signed-off-by: Steven Rostedt <[email protected]>
---
include/linux/init.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-compile.git/include/linux/init.h
===================================================================
--- linux-compile.git.orig/include/linux/init.h 2008-10-22 11:49:44.000000000 -0400
+++ linux-compile.git/include/linux/init.h 2008-10-22 12:27:19.000000000 -0400
@@ -75,15 +75,15 @@
#ifdef MODULE
-#define __exitused
+#define __exitused notrace
#else
-#define __exitused __used
+#define __exitused __used notrace
#endif
#define __exit __section(.exit.text) __exitused __cold
/* Used for HOTPLUG */
-#define __devinit __section(.devinit.text) __cold
+#define __devinit __section(.devinit.text) __cold notrace
#define __devinitdata __section(.devinit.data)
#define __devinitconst __section(.devinit.rodata)
#define __devexit __section(.devexit.text) __exitused __cold
@@ -91,7 +91,7 @@
#define __devexitconst __section(.devexit.rodata)
/* Used for HOTPLUG_CPU */
-#define __cpuinit __section(.cpuinit.text) __cold
+#define __cpuinit __section(.cpuinit.text) __cold notrace
#define __cpuinitdata __section(.cpuinit.data)
#define __cpuinitconst __section(.cpuinit.rodata)
#define __cpuexit __section(.cpuexit.text) __exitused __cold
@@ -99,7 +99,7 @@
#define __cpuexitconst __section(.cpuexit.rodata)
/* Used for MEMORY_HOTPLUG */
-#define __meminit __section(.meminit.text) __cold
+#define __meminit __section(.meminit.text) __cold notrace
#define __meminitdata __section(.meminit.data)
#define __meminitconst __section(.meminit.rodata)
#define __memexit __section(.memexit.text) __exitused __cold
--
Steven Rostedt wrote:
> The recordmcount script is now robust enough not to process any sections
> but the .text section. But the gcc compiler still adds a call to mcount.
>
> Note: The function mcount looks like:
>
> ENTRY(mcount)
> ret
> END(mcount)
>
> Which means the overhead is just a return.
>
> This patch adds notrace to the init sections to not even bother calling
> mcount (which simply returns).
Sorry for a potentially dumb question (didn't follow all recent ftrace
developments), but doesn't this mean that code in such sections is now
invisible for all tracers, even with dynamic tracing disabled (in which
case they should cause no problem)? What if you *do* want to have such
functions in your trace as they may contribute to problem or give other
useful hints?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
On Thu, 23 Oct 2008, Jan Kiszka wrote:
> Steven Rostedt wrote:
> > The recordmcount script is now robust enough not to process any sections
> > but the .text section. But the gcc compiler still adds a call to mcount.
> >
> > Note: The function mcount looks like:
> >
> > ENTRY(mcount)
> > ret
> > END(mcount)
> >
> > Which means the overhead is just a return.
> >
> > This patch adds notrace to the init sections to not even bother calling
> > mcount (which simply returns).
>
> Sorry for a potentially dumb question (didn't follow all recent ftrace
> developments), but doesn't this mean that code in such sections is now
> invisible for all tracers, even with dynamic tracing disabled (in which
> case they should cause no problem)? What if you *do* want to have such
> functions in your trace as they may contribute to problem or give other
> useful hints?
Not a dumb question, I've thought about this too.
Well, you can still add tracing into those functions, just the mcount call
will not be there. I've thought about other ways to handle this. Perhaps
add it only when DYNAMIC_FTRACE is configured. But that to me is a new
feature. The patches I'm submitting is to help with performance, bug
fixes, and sanity checks. So I left out any optional notraces.
e.g. in init.h I could do something like.
#ifdef CONFIG_DYNAMIC_FTRACE
# define init_notrace notrace
#else
# define init_notrace
#endif
And then use the init_notrace throughout the file. If this is considered
something that is acceptible for adding into 28, I would be happy to
supply a patch.
-- Steve
Steven Rostedt wrote:
> On Thu, 23 Oct 2008, Jan Kiszka wrote:
>
>> Steven Rostedt wrote:
>>> The recordmcount script is now robust enough not to process any sections
>>> but the .text section. But the gcc compiler still adds a call to mcount.
>>>
>>> Note: The function mcount looks like:
>>>
>>> ENTRY(mcount)
>>> ret
>>> END(mcount)
>>>
>>> Which means the overhead is just a return.
>>>
>>> This patch adds notrace to the init sections to not even bother calling
>>> mcount (which simply returns).
>> Sorry for a potentially dumb question (didn't follow all recent ftrace
>> developments), but doesn't this mean that code in such sections is now
>> invisible for all tracers, even with dynamic tracing disabled (in which
>> case they should cause no problem)? What if you *do* want to have such
>> functions in your trace as they may contribute to problem or give other
>> useful hints?
>
> Not a dumb question, I've thought about this too.
>
> Well, you can still add tracing into those functions, just the mcount call
> will not be there. I've thought about other ways to handle this. Perhaps
> add it only when DYNAMIC_FTRACE is configured. But that to me is a new
> feature. The patches I'm submitting is to help with performance, bug
> fixes, and sanity checks. So I left out any optional notraces.
Well, but mcount is only broken for .init sections if dynamic tracing is
on, no? Then I would focus the fix on that case as far as possible.
>
> e.g. in init.h I could do something like.
>
> #ifdef CONFIG_DYNAMIC_FTRACE
> # define init_notrace notrace
> #else
> # define init_notrace
> #endif
>
> And then use the init_notrace throughout the file. If this is considered
> something that is acceptible for adding into 28, I would be happy to
> supply a patch.
>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.
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...
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
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
* Steven Rostedt <[email protected]> wrote:
> > 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.
it dumps currently if a tracer is enabled. I saw it a couple of times
already during crashes.
Ingo
On Thu, 23 Oct 2008, Ingo Molnar wrote:
> * Steven Rostedt <[email protected]> wrote:
> >
> > 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.
>
> it dumps currently if a tracer is enabled. I saw it a couple of times
> already during crashes.
That's right. I owe you a patch. I'll write one up.
-- Steve