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. In my personal priority scheme, CONFIG_MCOUNT=y && !mcount_enabled comes after mcount_enabled. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
