public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hari Bathini <hbathini@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: daniel@iogearbox.net, peterz@infradead.org,
	linux-kernel@vger.kernel.org, acme@kernel.org,
	alexander.shishkin@linux.intel.com, mingo@redhat.com,
	paulus@samba.org, ebiederm@xmission.com, kernel@kyup.com,
	viro@zeniv.linux.org.uk, aravinda@linux.vnet.ibm.com,
	ananth@in.ibm.com
Subject: Re: [RFC PATCH v2 2/3] tracefs: add instances support for uprobe events
Date: Tue, 2 Aug 2016 22:57:30 +0530	[thread overview]
Message-ID: <17cdf475-e663-2ade-d69f-91440d654e98@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160801174546.0453ab85@gandalf.local.home>

Hi Steve,


Thanks for the review


On Tuesday 02 August 2016 03:15 AM, Steven Rostedt wrote:
> On Thu, 28 Jul 2016 02:57:38 +0530
> Hari Bathini <hbathini@linux.vnet.ibm.com> wrote:
>
>> If a uprobe event is set on a library function, and if a similar uprobe
>> event trace is needed for a container, a duplicate is created leaving
>> the uprobe list with multiple entries of the same function:
>>
>>    $ perf probe --list
>>      probe_libc:malloc    (on 0x80490 in /lib64/libc.so.6)
>>      probe_libc:malloc_1  (on __libc_malloc in /lib64/libc.so.6)
>>    $
>>
>> This can soon get out of hand if multiple containers want to probe the
>> same function/address in their libraries. This patch tries to resolve this
>> by adding uprobe event trace files to every new instance. Currently, perf
>> tool can leverage this by using --debugfs-dir option - something like
>> (assuming instance dir name is 'tracing'):
>>
>>    $ perf --debugfs-dir=$MOUNT_PNT/instances probe /lib64/libc.so.6 malloc
>>    $
>>    $
>>    $ perf --debugfs-dir=$MOUNT_PNT/instances probe --list
>>      probe_libc:malloc    (on __libc_malloc in /lib64/libc.so.6)
>>    $
>>
>> New uprobe events can be added to the uprobe_events file under the instance
>> directory and the profile information for these events will be available in
>> uprobe_profile file in the same instance directory.
> Hmm, this does change the behavior of normal instances.
>
> # cd /sys/kernel/debug/tracing
> # echo 'p /bin/bash:0x41adf0' > uprobe_events
> # ls events/uprobes
> enable filter p_bash_0x41adf0
>
> # mkdir instances/foo
> # ls instances/foo/events/uprobes
> ls: cannot access instances/foo/events/uprobes: No such file or directory
>
> Usually, instances will have the same events as the top level
> directory. This will make uprobes, and only uprobes different. I'm not
> sure if this is a bad thing or not, I'll have to think about it more.

Hmmm. I think making uprobes an exception is worth considering.

> But what would it take to have this only differ for containers, and not
> normal instances?

With the current approach, instances created in instances directory and
the ones created with newinstance mount option (patch 3 of 3) are similar.
Each instance corresponds to a trace_array structure.
An alternate approach I could think of is something like below:

struct trace_instance {
     struct trace_array tr;
     struct mutex uprobe_lock;
     struct list_head uprobe_list;
     /* any other new data specific to a mount instance */
};

where a mountable instance is more than a trace array.
This may need addition of new flags for trace array saying
whether it is a global trace or directory instance or mountable instance.
Also, the helper functions that add/remove events need to be tweaked 
accordingly.


Thanks
Hari

  reply	other threads:[~2016-08-02 17:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 21:27 [RFC PATCH v2 0/3] perf/tracefs: Container-aware tracing support Hari Bathini
2016-07-27 21:27 ` [RFC PATCH v2 1/3] perf: filter container events based on cgroup namespace Hari Bathini
2016-07-27 21:27 ` [RFC PATCH v2 2/3] tracefs: add instances support for uprobe events Hari Bathini
2016-08-01 21:45   ` Steven Rostedt
2016-08-02 17:27     ` Hari Bathini [this message]
2016-08-02 17:32       ` Hari Bathini
2016-08-02 17:49       ` Steven Rostedt
2016-08-03 19:30         ` Aravinda Prasad
2016-08-03 20:10           ` Steven Rostedt
2016-08-03 20:16             ` Aravinda Prasad
2016-08-04  1:04               ` Steven Rostedt
2016-08-04 13:46                 ` Aravinda Prasad
2016-08-04 14:08                   ` Steven Rostedt
2016-08-04 14:34                     ` Aravinda Prasad
2016-07-27 21:27 ` [RFC PATCH v2 3/3] tracefs: add 'newinstance' mount option Hari Bathini
2016-08-04  2:54   ` Eric W. Biederman
2016-08-04 12:26     ` Hari Bathini
2016-08-04 14:12       ` Eric W. Biederman
2016-08-04  2:59 ` [RFC PATCH v2 0/3] perf/tracefs: Container-aware tracing support Eric W. Biederman
2016-08-04 14:48   ` Aravinda Prasad
2016-08-04 18:27     ` Eric W. Biederman
2016-08-04 19:11       ` Aravinda Prasad

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=17cdf475-e663-2ade-d69f-91440d654e98@linux.vnet.ibm.com \
    --to=hbathini@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ananth@in.ibm.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=daniel@iogearbox.net \
    --cc=ebiederm@xmission.com \
    --cc=kernel@kyup.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    /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