From: Vince Weaver <firstname.lastname@example.org> To: Andy Lutomirski <email@example.com> Cc: Rob Herring <firstname.lastname@example.org>, "Peter Zijlstra (Intel)" <email@example.com>, Mark Rutland <firstname.lastname@example.org>, Will Deacon <email@example.com>, Kan Liang <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, Arnaldo Carvalho de Melo <email@example.com>, Alexander Shishkin <firstname.lastname@example.org>, Jiri Olsa <email@example.com>, Namhyung Kim <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, the arch/x86 maintainers <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, Dave Hansen <email@example.com>, firstname.lastname@example.org Subject: Re: [RFC 2/3] perf/x86: Control RDPMC access from .enable() hook Date: Sun, 29 Aug 2021 23:05:55 -0400 (EDT) [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> [-- Attachment #1: Type: text/plain, Size: 2056 bytes --] On Fri, 27 Aug 2021, Andy Lutomirski wrote: > On Thu, Aug 26, 2021, at 12:09 PM, Rob Herring wrote: > > After testing some scenarios and finding perf_event_tests, this > > series isn't going to work for x86 unless rdpmc is restricted to task > > events only or allowed to segfault on CPU events when read on the > > wrong CPU rather than just returning garbage. It's been discussed > > before here. > > > > Ultimately, I'm just trying to define the behavior for arm64 where we > > don't have an existing ABI to maintain and don't have to recreate the > > mistakes of x86 rdpmc ABI. Tying the access to mmap is messy. As we > > explicitly request user access on perf_event_open(), I think it may be > > better to just enable access when the event's context is active and > > ignore mmap(). Maybe you have an opinion there since you added the > > mmap() part? > > That makes sense to me. The mmap() part was always a giant kludge. > > There is fundamentally a race, at least if rseq isn’t used: if you check > that you’re on the right CPU, do RDPMC, and throw out the result if you > were on the wrong CPU (determined by looking at the mmap), you still > would very much prefer not to fault. > > Maybe rseq or a vDSO helper is the right solution for ARM. as the author of those perf_event tests for rdpmc, I have to say if ARM comes up with a cleaner implementation I'd be glad to have x86 transition to something better. The rdpmc code is a huge mess and has all kinds of corner cases. I'm not sure anyone besides the PAPI library tries to use it, and while it's a nice performance improvement to use rdpmc it is really hard to get things working right. As a PAPI developer we actually have run into the issue where the CPU switches and we were reporting the wrong results. Also if I recall (it's been a while) we were having issues where the setup lets you attach to a process on another CPU for monitoring using the rdpmc interface and it returns results even though I think that will rarely ever work in practice. Vince
next prev parent reply other threads:[~2021-08-30 3:07 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-28 23:02 [RFC 0/3] perf/x86: Rework RDPMC access handling Rob Herring 2021-07-28 23:02 ` [RFC 1/3] x86: perf: Move RDPMC event flag to a common definition Rob Herring 2021-07-28 23:02 ` [RFC 2/3] perf/x86: Control RDPMC access from .enable() hook Rob Herring 2021-08-12 16:50 ` Andy Lutomirski 2021-08-12 18:16 ` Rob Herring 2021-08-26 18:13 ` Andy Lutomirski 2021-08-26 19:09 ` Rob Herring 2021-08-27 21:10 ` Andy Lutomirski 2021-08-30 3:05 ` Vince Weaver [this message] 2021-08-30 8:51 ` Peter Zijlstra 2021-08-30 20:21 ` Vince Weaver 2021-08-30 21:40 ` Rob Herring 2021-08-30 20:58 ` Rob Herring 2021-07-28 23:02 ` [RFC 3/3] perf/x86: Call mmap event callbacks on event's CPU Rob Herring
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC 2/3] perf/x86: Control RDPMC access from .enable() hook' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).