All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@elte.hu>, Anton Arapov <anton@redhat.com>,
	Frank Eigler <fche@redhat.com>, Josh Stone <jistone@redhat.com>,
	"Suzuki K. Poulose" <suzuki@in.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/6] uprobes/perf: Always increment trace_uprobe->nhit
Date: Mon, 4 Feb 2013 21:56:11 +0530	[thread overview]
Message-ID: <20130204162611.GB28145@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130204151850.GA6641@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2013-02-04 16:18:50]:

> On 02/04, Srikar Dronamraju wrote:
> >
> > * Oleg Nesterov <oleg@redhat.com> [2013-01-31 20:18:32]:
> >
> > > Move tu->nhit++ from uprobe_trace_func() to uprobe_dispatcher().
> > >
> > > ->nhit counts how many time we hit the breakpoint inserted by this
> > > uprobe, we do not want to loose this info if uprobe was enabled by
> > > sys_perf_event_open().
> > >
> >
> > Though I dont see a problem with this change, It seems unnecessary for
> > me.
> >
> > Info from nhits is mostly for /sys/kernel/debug/tracing/uprobe_profile
> 
> It is only for uprobe_profile, yes, and it is useful. Why should we hide
> this info if this uprobe is used by perf?

Fine with me.

Steve, Masami, Do you have comments/suggestions on this. 
(Since kprobe_profile just accounts for kprobetracer and doesnt account
for perf record.)
May we should make a similar change in kprobetracer to keep things
similar.

-- 
Thanks and Regards
Srikar Dronamraju

> 
> > I am not sure how sys_perf_event_open() is making use of this?
> 
> I hope I'll send the final series today. From the changelog of the patch
> which actually turns the filtering on:
> 
> 	Testing:
> 
> 		# perf probe -x /lib/libc.so.6 syscall
> 
> 		# perl -e 'syscall -1 while 1' &
> 		[1] 530
> 
> 		# perf record -e probe_libc:syscall perl -e 'syscall -1 for 1..10; sleep 1'
> 
> 		# perf report --show-total-period
> 			100.00%            10     perl  libc-2.8.so    [.] syscall
> 
> 	Before this patch:
> 
> 		# cat /sys/kernel/debug/tracing/uprobe_profile
> 			/lib/libc.so.6 syscall				79291
> 
> 	A huge ->nrhit == 79291 reflects the fact that the background process
> 	530 constantly hits this breakpoint too, even if doesn't contribute to
> 	the output.
> 
> 	After the patch:
> 
> 		# cat /sys/kernel/debug/tracing/uprobe_profile
> 			/lib/libc.so.6 syscall				10
> 
> 	This shows that only the target process was punished by int3.
> 
> Oleg.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2013-02-04 16:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31 19:17 [PATCH 0/6] uprobes/tracing: cleanups and minor fixes Oleg Nesterov
2013-01-31 19:18 ` [PATCH 1/6] uprobes/tracing: Fix dentry/mount leak in create_trace_uprobe() Oleg Nesterov
2013-01-31 19:18 ` [PATCH 2/6] uprobes/tracing: Fully initialize uprobe_trace_consumer before uprobe_register() Oleg Nesterov
2013-01-31 19:18 ` [PATCH 3/6] uprobes/tracing: Ensure inode != NULL in create_trace_uprobe() Oleg Nesterov
2013-02-04 10:48   ` Srikar Dronamraju
2013-01-31 19:18 ` [PATCH 4/6] uprobes/tracing: Introduce is_trace_uprobe_enabled() Oleg Nesterov
2013-02-04 16:12   ` Srikar Dronamraju
2013-01-31 19:18 ` [PATCH 5/6] uprobes/tracing: Kill uprobe_trace_consumer, embed uprobe_consumer into trace_uprobe Oleg Nesterov
2013-02-04 16:59   ` Srikar Dronamraju
2013-02-04 17:20     ` Oleg Nesterov
2013-02-11  9:18       ` Srikar Dronamraju
2013-02-11  9:19   ` Srikar Dronamraju
2013-01-31 19:18 ` [PATCH 6/6] uprobes/perf: Always increment trace_uprobe->nhit Oleg Nesterov
2013-02-04 11:17   ` Srikar Dronamraju
2013-02-04 15:18     ` Oleg Nesterov
2013-02-04 16:26       ` Srikar Dronamraju [this message]
2013-02-04 16:34         ` Steven Rostedt
2013-02-11  9:19   ` Srikar Dronamraju

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=20130204162611.GB28145@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=anton@redhat.com \
    --cc=fche@redhat.com \
    --cc=jistone@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=suzuki@in.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 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.