From: Frederic Weisbecker <fweisbec@gmail.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
"K.Prasad" <prasad@linux.vnet.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
Jiri Slaby <jirislaby@gmail.com>, Li Zefan <lizf@cn.fujitsu.com>,
Avi Kivity <avi@redhat.com>, Mike Galbraith <efault@gmx.de>,
Masami Hiramatsu <mhiramat@redhat.com>,
Paul Mundt <lethal@linux-sh.org>, Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [PATCH 1/6] perf/core: Provide a kernel-internal interface to get to performance counters
Date: Mon, 2 Nov 2009 14:00:16 +0100 [thread overview]
Message-ID: <20091102130012.GA4878@nowhere> (raw)
In-Reply-To: <19182.47317.438053.553079@cargo.ozlabs.ibm.com>
On Mon, Nov 02, 2009 at 09:47:49PM +1100, Paul Mackerras wrote:
> Arjan van de Ven writes:
>
> > On Mon, 2 Nov 2009 14:46:55 +1100
> > Paul Mackerras <paulus@samba.org> wrote:
> >
> > > Frederic Weisbecker writes:
> > >
> > > > /*
> > > > + * perf_event_create_kernel_counter
> > > > + * MUST be called from a kernel thread.
> > >
> > > Why? The reason for this requirement isn't obvious to me. It would
> > > be good to have the reason documented in the comment for the sake of
> > > people modifying the code in future.
> >
> > because if you call it from another context it will attach to that
> > context... and go away when that context goes away...
>
> I don't think that's right. When a task exits, that doesn't
> automatically kill all the perf_events it created. The perf_events
> each have a reference to their owner's task_struct, so the task_struct
> will hang around until all of the perf_events get released. Normally
> top-level perf_events have an associated filp and we use its reference
> count to control the perf_event lifetime, but with these new kernel
> perf_events there is no filp, so the caller will have to do any
> refcounting required.
>
> Bottom line is that a perf_event created by
> perf_event_create_kernel_counter will exist until someone calls
> perf_event_release_kernel on it, whether or not the owner task exits
> (and whether or not that task is a kernel thread or a usermode
> process). So I see no need to prohibit creating kernel perf_events in
> the context of a user task, though callers need to be aware that doing
> so could potentially mean the user task's task_struct has to hang
> around for a long time after the task exits.
>
> Paul.
Yeah. For example while creating a breakpoint through ptrace,
the owner of an event created by perf_event_create_kernel_counter
is the user task that does the ptrace call.
But we need to explicitly release some disabled/pending ptrace
breakpoints using perf_event_release_kernel when the task exits.
I should simplify this part in the future.
That said, it's all fine to set the owner as a user task like in this
example.
Should I remove this comment?
next prev parent reply other threads:[~2009-11-02 13:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-24 14:16 [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events Frederic Weisbecker
2009-10-24 14:16 ` [PATCH 1/6] perf/core: Provide a kernel-internal interface to get to performance counters Frederic Weisbecker
2009-10-24 14:16 ` [PATCH 2/6] x86/hw-breakpoints: Actually flush thread breakpoints in flush_thread() Frederic Weisbecker
2009-10-24 14:16 ` [PATCH 3/6] perf/core: Add a callback to perf events Frederic Weisbecker
2009-10-24 14:16 ` [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer on top of " Frederic Weisbecker
2009-10-24 16:19 ` Jan Kiszka
2009-10-25 23:31 ` Frederic Weisbecker
2009-10-26 8:17 ` Jan Kiszka
2009-11-01 21:09 ` [GIT PULL v3] hw-breakpoints: Rewrite " Frederic Weisbecker
2009-11-01 21:09 ` [PATCH 1/6] perf/core: Provide a kernel-internal interface to get to performance counters Frederic Weisbecker
2009-11-02 3:46 ` Paul Mackerras
2009-11-02 5:38 ` Arjan van de Ven
2009-11-02 10:47 ` Paul Mackerras
2009-11-02 13:00 ` Frederic Weisbecker [this message]
2009-11-01 21:09 ` [PATCH 2/6] x86/hw-breakpoints: Actually flush thread breakpoints in flush_thread() Frederic Weisbecker
2009-11-01 21:09 ` [PATCH 3/6] perf/core: Add a callback to perf events Frederic Weisbecker
2009-11-02 3:49 ` Paul Mackerras
2009-11-02 13:01 ` Frederic Weisbecker
2009-11-01 21:09 ` [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer on top of " Frederic Weisbecker
2009-11-01 22:09 ` Jan Kiszka
2009-11-01 22:49 ` Frederic Weisbecker
2009-11-01 23:37 ` Frederic Weisbecker
2009-11-02 7:45 ` Jan Kiszka
2009-11-02 13:04 ` Frederic Weisbecker
2009-11-01 21:09 ` [PATCH 5/6] hw-breakpoints: Arbitrate access to pmu following registers constraints Frederic Weisbecker
2009-11-01 21:09 ` [PATCH 6/6] ksym_tracer: Remove KSYM_SELFTEST_ENTRY Frederic Weisbecker
2009-10-24 14:16 ` [PATCH 5/6] hw-breakpoints: Arbitrate access to pmu following registers constraints Frederic Weisbecker
2009-10-24 14:16 ` [PATCH 6/6] ksym_tracer: Remove KSYM_SELFTEST_ENTRY Frederic Weisbecker
2009-10-24 14:19 ` [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events Frederic Weisbecker
2009-10-26 21:31 ` K.Prasad
2009-10-29 19:07 ` Frederic Weisbecker
2009-11-02 6:25 ` K.Prasad
2009-11-02 14:07 ` Frederic Weisbecker
2009-11-04 14:14 ` K.Prasad
2009-11-05 11:02 ` Frederic Weisbecker
-- strict thread matches above, loose matches on Subject: below --
2009-11-03 19:11 [GIT PULL v4] hw-breakpoints: Rewrite on top of perf events v4 Frederic Weisbecker
2009-11-03 19:11 ` [PATCH 1/6] perf/core: Provide a kernel-internal interface to get to performance counters Frederic Weisbecker
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=20091102130012.GA4878@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=arjan@infradead.org \
--cc=arjan@linux.intel.com \
--cc=avi@redhat.com \
--cc=efault@gmx.de \
--cc=jan.kiszka@siemens.com \
--cc=jan.kiszka@web.de \
--cc=jirislaby@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
/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.