linux-kernel - Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131008193927.GB7315@gmail.com>
Date:	Tue, 8 Oct 2013 21:39:27 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	Andi Kleen <ak@...ux.intel.com>, fweisbec@...il.com
Subject: Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS


* Steven Rostedt <rostedt@...dmis.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/