* Steven Rostedt <rost...@goodmis.org> wrote:
> On Tue, Oct 08, 2013 at 08:59:38AM +0200, Ingo Molnar wrote:
> >
> > Secondly and more importantly, visualized with relative sizes, in a
> > feature matrix, makes it clearer what's going on with vmlinux .text:
> >
> > perf-OFF perf-ON
> >
> > ftrace-OFF 0 +151k
> >
> > ftrace-ON +897k +1142k
> >
> > So basically ftrace is causing a big chunk of the instrumentation size
> > increase. With tons of tracers and lots of kernel subsystems built into
> > your .config that's a lot of nice instrumentation functionality and it's
> > thus also a natural end result IMO.
>
> I'm curious what you turned on for between the "ftrace-OFF" and "ftrace-ON"?
ON: all the tracing bits in Andi's original config - which had most
tracing options enabled AFAICS.
OFF: all of it turned off.
I don't think there's anything inherently wrong with 3000+ tracepoints
built into the kernel using up a fair amount of cold-path space. We should
try to compress it all, but it's a hell of a lot real functionality.
> The one thing that you didn't post was CONFIG_EVENT_TRACING. This is
> where a lot of bloat can come from, as this enables the infrastructure
> for tracepoints. This is also needed by perf to trace most sw events.
Correct.
EVENT_TRACING was on - Andi did not post his .config publicly, but you can
get something fairly close to his config by doing this:
make defconfig
cat config-options.txt >> .config
make oldconfig
where 'config-options.txt' is the short list of options I appended to my
mail.
> The trace event infrastructure that both perf and ftrace uses (as well
> as other tracers and tools) is well known to cause bloat in the kernel.
> There's patches to help make it more bearable, but there's more work to
> be done.
It's 3000+ very nice tracepoints - which is a huge multiplier, so we
should not expect any miracles - it's a whole lot of good functionality.
Subsystems can decide whether they want to expose their tracepoints or
not.
Thanks,
Ingo
--
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/
