From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, acme@redhat.com,
kirill.shutemov@linux.intel.com, rric@kernel.org
Subject: Re: [RFC PATCH 00/17] perf: Detached events
Date: Wed, 13 Sep 2017 14:54:02 +0300 [thread overview]
Message-ID: <87a81yx19h.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <20170906162414.djyec6rlu2ktzdag@pd.tnic>
Borislav Petkov <bp@alien8.de> writes:
> On Tue, Sep 05, 2017 at 04:30:09PM +0300, Alexander Shishkin wrote:
>> Detached events: a new flag to the perf syscall makes a 'detached' event,
>> which exists after its file descriptor is released. Not all detached events
>> are per-thread AUX events: this tries to take into account the need for
>> system-wide persistent events too.
>
> Nice, thanks!
Forgot to mention that I did hack the tracepoint support into the
tooling as well to make sure it's a workable idea.
>> (2) Need to be able to kill those events, so they need to be accessible
>> after they are created.
>> Event files: detached events exist as files in tracefs (at the moment), can
>> be opened/mmaped/read/removed.
>
> I guess I'll see when I continue reading but I remember us doing ioctls
> on the event fd.
Iirc that was for re-attaching to the event to make it 'normal' before
closing.
>> (6) Ring buffer memory accounting needs to take this new arrangement into
>> account: one user can use up at most NR_CPUS * buffer_size memory at any
>> given point in time.
>> Only account the first such event and undo the accounting when the last
>> event is gone.
>
> ... and I guess we probably shouldn't allow the user to create too many
> events and shoot herself in the OOM-foot.
Well, they are still limited by the RLIMIT_MEMLOCK and perf_event_mlock
sysctl for the total amount of memory that can be pinned for the ring
buffers at any given time, so that should be fine.
>> (7) We'll also need to supply all the things that the [PT] decoder normally
>> finds out via sysfs attributes, like clock ratios, capabilities, etc so that
>> it also finds its way into the core dump file.
>> "PMU info" structure is appended to the user page.
>>
>> I've also hack the perf tool to support all this, all these things can be
>> found at [1]. I'm not posting the tooling patches though, them being
>> thoroughly ugly and proof-of-concept. In short, perf record will create
>> detached events with '--detached' and afterwards will open detached events
>> via their path in tracefs.
>
> Sounds nice. I'd need to test all that just so I can be able to create
> detached RAS events (which are tracepoints) with it.
Thanks, let me know how it goes.
Regards,
--
Alex
prev parent reply other threads:[~2017-09-13 12:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 13:30 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
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 [this message]
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=87a81yx19h.fsf@ashishki-desk.ger.corp.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.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®