From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Alex Ray <alexjray.ncsu@gmail.com>,
v9fs-developer@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Alex Ray <ajray@ncsu.edu>
Subject: Re: [PATCH] 9p: remove CONFIG_NET_9P_DEBUG option
Date: Wed, 10 Aug 2011 22:47:39 +0530 [thread overview]
Message-ID: <87wrel5gp8.fsf@skywalker.in.ibm.com> (raw)
In-Reply-To: <CAFkjPT=y4jJTNEFrJLr=i9UVHfixqqGmYbVZf0B4AHk-AmOJdA@mail.gmail.com>
On Wed, 10 Aug 2011 07:24:56 -0500, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Wed, Aug 10, 2011 at 4:13 AM, Aneesh Kumar K.V
> <aneesh.kumar@linux.vnet.ibm.com> wrote:
> >
> > On Mon, 1 Aug 2011 07:14:44 -0500, Alex Ray <alexjray.ncsu@gmail.com> 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@ncsu.edu>
> >
> > 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.
> Now, one could
> make a case that we have too many DPRINT and need to cut back, but if
> that's the case, let's just get around to it and cleanup a bit.
>
> All that being said, I welcome anyone to send me performance with and
> without CONFIG_NET_9P_DEBUG turned on to convince me differently.
With tracepoints we should not have much performance impact when tracing is
disabled. So may be the right way to go forward is to convert enough P9_DPRINT
to tracepoint that will aid in better debugging of errors, and retain
CONFIG_NET_9P_DEBUG as it is.
I actually converted protocol dump to tracepoints. Other advantages
of switching to tracepoints is the ability to get stack trace,
filtering debug output per mount points, integration with perf tool.
I guess if we can list out which set of P9_DPRINTK will aid better
reporting of bugs then we can look at converting them to
tracepoints. Protocol dump was the immediate one which I found useful.
-aneesh
next prev parent reply other threads:[~2011-08-10 17:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-01 12:14 [PATCH] 9p: remove CONFIG_NET_9P_DEBUG option Alex Ray
2011-08-03 4:34 ` Aneesh Kumar K.V
2011-08-10 9:13 ` Aneesh Kumar K.V
2011-08-10 12:24 ` Eric Van Hensbergen
2011-08-10 17:17 ` Aneesh Kumar K.V [this message]
2011-08-10 18:36 ` Eric Van Hensbergen
2011-08-11 15:54 ` Aneesh Kumar K.V
2011-08-11 16:05 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wrel5gp8.fsf@skywalker.in.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=ajray@ncsu.edu \
--cc=alexjray.ncsu@gmail.com \
--cc=ericvh@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=v9fs-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).