From: Peter Zijlstra <peterz@infradead.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, acme@redhat.com,
kirill.shutemov@linux.intel.com, Borislav Petkov <bp@alien8.de>,
rric@kernel.org
Subject: Re: [RFC PATCH 05/17] perf: Introduce detached events
Date: Tue, 3 Oct 2017 16:34:38 +0200 [thread overview]
Message-ID: <20171003143438.e4xfwcv7sl4mtplx@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20170905133026.13689-6-alexander.shishkin@linux.intel.com>
On Tue, Sep 05, 2017 at 04:30:14PM +0300, Alexander Shishkin wrote:
> There are usecases where it is desired to have perf events without the
> userspace tool running in the background to keep them alive, but instead
> only collect the data when it is needed, for example when an MCE event
> is triggered.
>
> This patch adds a new flag to the perf_event_open() syscall that allows
> creating such events. Once created, the file descriptor can be closed
> and the event continues to exist on its own. To allow access to this
> event, a file is created in the tracefs, which the user can open.
>
> Finally, when it is no longer needed, it can be destroyed by unlinking
> the file.
>
> @@ -9387,6 +9416,27 @@ static void account_event(struct perf_event *event)
> account_pmu_sb_event(event);
> }
>
> +static int perf_event_detach(struct perf_event *event, struct task_struct *task,
> + struct mm_struct *mm)
> +{
> + char *filename;
> +
> + filename = kasprintf(GFP_KERNEL, "%s:%x.event",
> + task ? "task" : "cpu",
> + hash_64((u64)event, PERF_TRACEFS_HASH_BITS));
> + if (!filename)
> + return -ENOMEM;
> +
> + event->dent = tracefs_create_file(filename, 0600,
> + perf_tracefs_dir,
> + event, &perf_fops);
> + kfree(filename);
> +
> + if (!event->dent)
> + return -ENOMEM;
> +
> + return 0;
> +}
So I'm not opposed to the idea of creating events that live independent
from of file descriptors. And stuffing them in a filesystem makes sense.
However I'm not entire convinced on the details.
The above has a number of problems:
- there's a filesystem race; two concurrent syscalls can try and create
the same file. In that case the error most certainly is not -ENOMEM.
- there's a hash collision, similar issue.
- there's some asymmetry in the create/destroy; that is you create the
file with sys_perf_event_open() and remove it with unlink().
- the actual name is very opaque and hard to use; how would a tool find
the right event to open?
Would it instead make sense to allow the user to creat() their own files
in this filesystem (with whatever descriptive name they need) and then
pass that fd like:
sys_perf_event_open(.group_fd=fd, .flags=PERF_FLAG_FD_DETACH);
or something to associate the file with the event. Of course, that makes
it very hard to create detached cgroup events :/
next prev parent reply other threads:[~2017-10-03 14:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 13:30 [RFC PATCH 00/17] perf: Detached events Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 01/17] perf: Allow mmapping only user page Alexander Shishkin
2017-09-06 16:28 ` Borislav Petkov
2017-09-13 11:35 ` Alexander Shishkin
2017-09-13 12:58 ` Borislav Petkov
2017-09-05 13:30 ` [RFC PATCH 02/17] perf: Factor out mlock accounting Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 03/17] tracefs: De-globalize instances' callbacks Alexander Shishkin
2018-01-24 18:54 ` Steven Rostedt
2017-09-05 13:30 ` [RFC PATCH 04/17] tracefs: Add ->unlink callback to tracefs_dir_ops Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 05/17] perf: Introduce detached events Alexander Shishkin
2017-10-03 14:34 ` Peter Zijlstra [this message]
2017-10-06 11:23 ` Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 06/17] perf: Add buffers to the " Alexander Shishkin
2017-10-03 14:36 ` Peter Zijlstra
2017-09-05 13:30 ` [RFC PATCH 07/17] perf: Add pmu_info to user page Alexander Shishkin
2017-10-03 14:40 ` Peter Zijlstra
2017-09-05 13:30 ` [RFC PATCH 08/17] perf: Allow inheritance for detached events Alexander Shishkin
2017-10-03 14:42 ` Peter Zijlstra
2017-10-06 11:40 ` Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 09/17] perf: Use shmemfs pages for userspace-only per-thread " Alexander Shishkin
2017-10-03 14:43 ` Peter Zijlstra
2017-10-06 11:52 ` Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 10/17] perf: Implement pinning and scheduling for SHMEM events Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 11/17] perf: Implement mlock accounting for shmem ring buffers Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 12/17] perf: Track pinned events per user Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 13/17] perf: Re-inject shmem buffers after exec Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 14/17] perf: Add ioctl(REATTACH) for detached events Alexander Shishkin
2017-10-03 14:50 ` Peter Zijlstra
2017-09-05 13:30 ` [RFC PATCH 15/17] perf: Allow controlled non-root access to " Alexander Shishkin
2017-10-03 14:53 ` Peter Zijlstra
2017-09-05 13:30 ` [RFC PATCH 16/17] perf/x86/intel/pt: Add PMU info Alexander Shishkin
2017-09-05 13:30 ` [RFC PATCH 17/17] perf/x86/intel/bts: " Alexander Shishkin
2017-09-06 16:24 ` [RFC PATCH 00/17] perf: Detached events Borislav Petkov
2017-09-13 11:54 ` Alexander Shishkin
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=20171003143438.e4xfwcv7sl4mtplx@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rric@kernel.org \
/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
all inboxes | Powered by JetHome®