From: Greg KH <gregkh@linuxfoundation.org>
To: Gaurav Kohli <gkohli@codeaurora.org>
Cc: akpm@linux-foundation.org,
linux-kernel <linux-kernel@vger.kernel.org>,
tglx@linutronix.de, linux-arm-msm@vger.kernel.org,
neeraju@codeaurora.org
Subject: Re: Query: Regarding Notifier chain callback debugging or profiling
Date: Mon, 10 Feb 2020 13:06:26 -0800 [thread overview]
Message-ID: <20200210210626.GA1373304@kroah.com> (raw)
In-Reply-To: <6e077b43-6c9e-3f4e-e079-db438e36a4eb@codeaurora.org>
On Mon, Feb 10, 2020 at 05:26:16PM +0530, Gaurav Kohli wrote:
> Hi,
>
> In Linux kernel, everywhere we are using notification chains to notify for
> any kernel events, But we don't have any debugging or profiling mechanism to
> know which callback is taking time or currently we are stuck on which call
> back(without dumps it is difficult to say for last problem)
Callbacks are a mess, I agree.
> Below are the few ways, which we can implement to profile callback on need
> basis:
>
> 1) Use trace event before and after callback:
>
> static int notifier_call_chain(struct notifier_block **nl,
> unsigned long val, void *v,
> int nr_to_call, int *nr_calls)
> {
> int ret = NOTIFY_DONE;
> struct notifier_block *nb, *next_nb;
>
>
> + trace_event for entry of callback
> ret = nb->notifier_call(nb, val, v);
> + trace_event for exit of callback
Ick.
> }
> return ret;
> }
>
> 2) Or use pr_debug instead of trace_event
>
> 3) Both of the above approach has certain problems, like it will dump
> callback for each notifier chain, which might flood trace buffer or dmesg.
>
> So we can use bool variable to control that and dump the required
> notification chain only.
>
> Some thing like below we can use:
>
> struct srcu_notifier_head {
> struct mutex mutex;
> struct srcu_struct srcu;
> struct notifier_block __rcu *head;
> + bool debug_callback;
> };
>
>
> static int notifier_call_chain(struct notifier_block **nl,
> unsigned long val, void *v,
> - int nr_to_call, int *nr_calls)
> + int nr_to_call, int *nr_calls, bool
> debug_callback)
> {
> int ret = NOTIFY_DONE;
> struct notifier_block *nb, *next_nb;
> @@ -526,6 +526,7 @@ void srcu_init_notifier_head(struct srcu_notifier_head
> *nh)
> if (init_srcu_struct(&nh->srcu) < 0)
> BUG();
> nh->head = NULL;
> + nh->debug_callback = false; -> by default it would be false for
> every notifier chain.
>
> 4) we can also think of something pre and post function, before and after
> each callback, And we can enable only for those who wants to profile.
>
> Please let us what approach we can use, or please suggest some debugging
> mechanism for the same.
Why not just pay attention to the specific notifier you want? Trace
when the specific blocking_notifier_call_chain() is called.
What specific notifier call chain is causing you problems that you need
to debug?
thanks,
greg k-h
next prev parent reply other threads:[~2020-02-10 21:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <82d5b63e-4ae6-fb5f-8a1c-2d5755db2638@codeaurora.org>
2020-02-10 11:56 ` Gaurav Kohli
2020-02-10 21:06 ` Greg KH [this message]
2020-02-11 4:46 ` Gaurav Kohli
2020-02-11 12:20 ` Greg KH
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=20200210210626.GA1373304@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=gkohli@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraju@codeaurora.org \
--cc=tglx@linutronix.de \
/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
Powered by JetHome