Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS

[Ingo Molnar <mingo@kernel.org>]

* Steven Rostedt <rostedt@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