linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>, robh+dt@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, nfont@linux.vnet.ibm.com,
	mpe@ellerman.id.au, rostedt@goodmis.org, mingo@redhat.com
Subject: Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
Date: Tue, 18 Apr 2017 17:07:17 -0700	[thread overview]
Message-ID: <58F6AA35.2040902@gmail.com> (raw)
In-Reply-To: <1492475525-10827-1-git-send-email-tyreld@linux.vnet.ibm.com>

On 04/17/17 17:32, Tyrel Datwyler wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
> 
> With the recent upstreaming of the refcount API several device_node
> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
> resources at runtime such as cpus or IOAs). These tracepoints provide a
> easy and quick mechanism for validating the reference counting of
> device_nodes during their lifetime.
> 
> Further, when pseries lpars are migrated to a different machine we
> perform a live update of our device tree to bring it into alignment with the
> configuration of the new machine. The of_reconfig_notify trace point
> provides a mechanism that can be turned for debuging the device tree
> modifications with out having to build a custom kernel to get at the
> DEBUG code introduced by commit 00aa3720.

I do not like changing individual (or small groups of) printk() style
debugging information to tracepoint style.

As far as I know, there is no easy way to combine trace data and printk()
style data to create a single chronology of events.  If some of the
information needed to debug an issue is trace data and some is printk()
style data then it becomes more difficult to understand the overall
situation.

If Rob wants to convert printk() style data to trace data (and I can't
convince him otherwise) then I will have further comments on this specific
patch.

-Frank

> 
> The following trace events are provided: of_node_get, of_node_put,
> of_node_release, and of_reconfig_notify. These trace points require a kernel
> built with ftrace support to be enabled. In a typical environment where
> debugfs is mounted at /sys/kernel/debug the entire set of tracepoints
> can be set with the following:
> 
>   echo "of:*" > /sys/kernel/debug/tracing/set_event
> 
> or
> 
>   echo 1 > /sys/kernel/debug/tracing/of/enable
> 
> The following shows the trace point data from a DLPAR remove of a cpu
> from a pseries lpar:
> 
> cat /sys/kernel/debug/tracing/trace | grep "POWER8@10"
> 
> cpuhp/23-147   [023] ....   128.324827:
> 	of_node_put: refcount=5, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147   [023] ....   128.324829:
> 	of_node_put: refcount=4, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147   [023] ....   128.324829:
> 	of_node_put: refcount=3, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147   [023] ....   128.324831:
> 	of_node_put: refcount=2, dn->full_name=/cpus/PowerPC,POWER8@10
>    drmgr-7284  [009] ....   128.439000:
> 	of_node_put: refcount=1, dn->full_name=/cpus/PowerPC,POWER8@10
>    drmgr-7284  [009] ....   128.439002:
> 	of_reconfig_notify: action=DETACH_NODE, dn->full_name=/cpus/PowerPC,POWER8@10,
> 			    prop->name=null, old_prop->name=null
>    drmgr-7284  [009] ....   128.439015:
> 	of_node_put: refcount=0, dn->full_name=/cpus/PowerPC,POWER8@10
>    drmgr-7284  [009] ....   128.439016:
> 	of_node_release: dn->full_name=/cpus/PowerPC,POWER8@10, dn->_flags=4
> 
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> ---
>  drivers/of/dynamic.c      | 30 ++++++---------
>  include/trace/events/of.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 105 insertions(+), 18 deletions(-)
>  create mode 100644 include/trace/events/of.h
> 

< snip >

  parent reply	other threads:[~2017-04-19  0:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18  0:32 [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle Tyrel Datwyler
2017-04-18  0:35 ` Tyrel Datwyler
2017-04-18 16:46 ` Rob Herring
2017-04-19  2:30   ` Oliver O'Halloran
2017-04-19 10:13     ` Michael Ellerman
2017-04-19 21:13       ` Tyrel Datwyler
2017-04-19  0:07 ` Frank Rowand [this message]
2017-04-19  1:31   ` Michael Ellerman
2017-04-19  2:31     ` Frank Rowand
2017-04-19 18:33       ` Tyrel Datwyler
2017-04-19 23:27     ` Tyrel Datwyler
2017-04-20  2:33       ` Steven Rostedt
2017-04-20  4:47         ` Frank Rowand
2017-04-20  5:24         ` Tyrel Datwyler
2017-04-20 13:37           ` Steven Rostedt
2017-04-20  4:43       ` Frank Rowand
2017-04-20  5:13         ` Frank Rowand
2017-04-20 16:51         ` Tyrel Datwyler
2017-04-20 19:34           ` Frank Rowand
2017-04-21  1:57             ` Michael Ellerman
2017-04-19  1:42   ` Frank Rowand
2017-04-19  2:49     ` Steven Rostedt
2017-04-19 18:45       ` Tyrel Datwyler
2017-04-20  2:37         ` Frank Rowand
2017-04-20 10:44           ` Frank Rowand
2017-04-19  2:46   ` Steven Rostedt
2017-04-19  3:12     ` Frank Rowand
2017-04-19 17:44 ` Frank Rowand

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=58F6AA35.2040902@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=robh+dt@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tyreld@linux.vnet.ibm.com \
    /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).