linux-kernel - Re: [PATCH 0/18] Allow different tracers to be compiled independently

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: <20100326002029.GH3145@quack.suse.cz>
Date:	Fri, 26 Mar 2010 01:20:29 +0100
From:	Jan Kara <jack@...e.cz>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Jan Kara <jack@...e.cz>, Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Li Zefan <lizf@...fujitsu.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/18] Allow different tracers to be compiled
 independently

On Tue 23-03-10 02:04:21, Frederic Weisbecker wrote:
> On Tue, Mar 23, 2010 at 01:32:02AM +0100, Jan Kara wrote:
> > 
> >   Hi,
> > 
> >   currently, when one tracer is selected, most of tracepoints for other
> > tracers also gets pulled into the kernel. So for example it's not possible
> > to enable BLK_DEV_IO_TRACE without polluting slab allocation paths with
> > tracepoint checks (see changelog of patch 01). This patch set adds a
> > possibility for each set of trace points to be compile-enabled separately.
> >   The first patch contains the necessary magic in linux/tracepoint.h. Other
> > patches just tell tracing framework about correspoding config options
> > and possibly introduce them if they did not exist before.
> >   The patches in this patch set are actually completely independent so 
> > they can be merged via respective subsystem trees. But changes are rather
> > tiny so I don't expect much conflicts...
> > 
> > 								Honza
> 
> (Adding more people in Cc)
> 
> I don't know. Yeah this first looks like a good idea but once
> CONFIG_EVENT_TRACING is enabled, each tracepoint is a lightweight
> thing and induce a tiny overhead, probably hard to notice, and
> this is going to be even more the case after the jmp label
> optimization patches.
  Sorry for replying late, I was on vacation. My motivation was that we
wanted BLK_DEV_IO_TRACE enabled in all our distro kernels but there is
a concern that this could have some impact on performance especially
in SLAB allocator due to more icache pressure or so. This is not completely
bogus concern if you look at bloat-o-meter output. For example:
function                                     old     new   delta
kmem_cache_alloc                             542     768    +226

  But looking at the disassembly now, I can see that the difference in
inline code is actually only ~40 bytes (on x86_64) - so that's about 7%.
Not a huge deal but still noticeable. 

> I liked the fact we had a general tracing kernel once the above
> config is selected. And we don't bother telling people that to
> use tool X you need CONFIG_EVENT_Y, and you need to rebuild your
> kernel, etc...
  OK, I understand this. I guess I should go and measure whether disabling
tracepoints really makes some performance difference or not.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/