linux-kernel - Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation

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]

Date:	Wed, 30 Jan 2008 08:53:24 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jan Kiszka <jan.kiszka@...mens.com>
cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Bird <tim.bird@...sony.com>,
	Sam Ravnborg <sam@...nborg.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	John Stultz <johnstul@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation


On Wed, 30 Jan 2008, Jan Kiszka wrote:

> Steven Rostedt wrote:
>
> > --- linux-mcount.git.orig/arch/x86/kernel/entry_32.S	2008-01-29 16:59:15.000000000 -0500
> > +++ linux-mcount.git/arch/x86/kernel/entry_32.S	2008-01-29 17:26:18.000000000 -0500
> > @@ -75,6 +75,31 @@ DF_MASK		= 0x00000400
> >  NT_MASK		= 0x00004000
> >  VM_MASK		= 0x00020000
> >
> > +#ifdef CONFIG_MCOUNT
> > +.globl mcount
> > +mcount:
> > +	/* unlikely(mcount_enabled) */
> > +	cmpl $0, mcount_enabled
> > +	jnz trace
> > +	ret
>
> (and the corresponding 64-bit version)
>
> Is the impact of this change on the (already expensive) mcount_enabled
> case negligible? I worried about use cases where we want to gain some
> (relative) worst-case numbers via these instrumentations.

The goal here was to limit the instruction cache hit that we take when
mcount_enabled = 0.
>
> In my personal priority scheme, CONFIG_MCOUNT=y && !mcount_enabled comes
> after mcount_enabled.

well, actually, I disagree. I only set mcount_enabled=1 when I'm about to
test something. You're right that we want the impact of the test least
affected, but when we have mcount_enabled=1 we usually also have a
function that's attached and in that case this change is negligible. But
on the normal case where mcount_enabled=0, this change may have a bigger
impact.

Remember CONFIG_MCOUNT=y && mcount_enabled=0 is (15% overhead)
         CONFIG_MCOUNT=y && mcount_enabled=1 dummy func (49% overhead)
         CONFIG_MCOUNT=y && mcount_enabled=1 trace func (500% overhead)

The trace func is the one that will be most likely used when analyzing. It
gives hackbench a 500% overhead, so I'm expecting this change to be
negligible in that case. But after I find what's wrong, I like to rebuild
the kernel without rebooting so I like to have mcount_enabled=0 have the
smallest impact ;-)

I'll put back the original code and run some new numbers.

-- Steve

--
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/