On Wed, 10 Aug 2011 13:36:52 -0500, Eric Van Hensbergen <ericvh@xxxxxxxxx> wrote: > On Wed, Aug 10, 2011 at 12:17 PM, Aneesh Kumar K.V > <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 10 Aug 2011 07:24:56 -0500, Eric Van Hensbergen <ericvh@xxxxxxxxx> wrote: > >> On Wed, Aug 10, 2011 at 4:13 AM, Aneesh Kumar K.V > >> <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote: > >> > On Mon, 1 Aug 2011 07:14:44 -0500, Alex Ray <alexjray.ncsu@xxxxxxxxx> wrote: > >> >> Remove the CONFIG_NET_9P_DEBUG option, used to completely remove logging > >> >> functionality from v9fs. Logging is (already) controlled with the > >> >> run-time debug= option, this gets rid of the compile-time option (which > >> >> was being misunderstood and misused). > >> >> > >> >> Signed-off-by: Alex Ray <ajray@xxxxxxxx> > >> > > >> > I see this merged to for-next. Do we know whether enabling debug always have a > >> > performance impact ?. > >> > > >> > >> No clue, but without any debug it makes it impossible for user's to > >> generate reasonable bug reports. If I understand the tracepoint > >> collection facility correctly, it incurs exactly the same overhead as > >> a DPRINT when the debug mount option is set to 0 (although tracepoints > >> are much lower overhead when actually collecting). > > > > I was worried about overhead when we are not collecting any debug info. > > > > I understand that. But the overhead when not collecting is the > conditional branch. > According to Documentation/trace/tracepoints.txt this is the same for the > tracepoints: > > "When a tracepoint is "off" it has no effect, except for adding a tiny > time penalty > (checking a condition for a branch) and space penalty (adding a few > bytes for the function call at the end of the instrumented function > and adds a data structure in a separate section)." > > So, since DPRINT is essentially if(p9_debug_level & level) == level) > it should roughly amount to the same overhead, no? I suppose we could > get fancy and and prefix it with an unlikely. > Is that true with jump label ? May be we should update tracepoints.txt ? Upstream commit: bf5438fca2950b03c21ad868090cc1a8fcd49536 8f7b50c514206211cc282a4247f7b12f18dee674 -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html