On Thu, 2011-08-11 at 21:24 +0530, Aneesh Kumar K.V wrote: > 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 ? Correct, that should be updated. When jump labels are enabled, we have a nop and an unconditional branch over the trace code, which when enable will change the nop to call the trace code. We do have a slight hit in icache, but nothing I have been able to measure. But if we do, I could even modify it to become even less of an impact (but will cause tracing to slow down, but we don't really care if it speeds up non tracing case ;) -- Steve > > 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
