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 ` Query: Regarding Notifier chain callback debugging or profiling 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.