From: Rob Herring <firstname.lastname@example.org> To: Vince Weaver <email@example.com> Cc: Andy Lutomirski <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: Mon, 30 Aug 2021 15:58:28 -0500 [thread overview] Message-ID: <CAL_JsqLs9Wbdbso0_XdijME=zDK9=5yKpi1a1NQM6j1qNczWbg@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Sun, Aug 29, 2021 at 10:06 PM Vince Weaver <firstname.lastname@example.org> wrote: > > 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. There was a version using rseq. AIUI, that would solve the reading from the wrong CPU problem. I don't think using rseq would change the kernel implementation other than whether we enable events on specific CPUs. > 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. Thanks for chiming in. My plan is to be more restricted in terms of what works, and fail or disable user access for what's not supported. Unless I hear events on specific CPUs is really important, that means only monitoring of a thread on all (for big.LITTLE, all homogeneous) CPUs is supported. That doesn't require a better/cleaner interface. It just means cpu must be -1 for perf_event_open if you want rdpmc. The difference on Arm is just that we can enforce/indicate that. We could also enable CPU events, but abort if read on the wrong CPU. The user in that case either has to control the thread affinity or possibly use rseq. > 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. Yes, I've been reading thru the bugs you reported and related tests. I just wish I found them sooner... > 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. Returning the wrong results is obviously bad for the user, but making that "work" also complicates the kernel implementation. Rob  https://email@example.com/
next prev parent reply other threads:[~2021-08-30 20:58 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 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 [this message] 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 \ --in-reply-to='CAL_JsqLs9Wbdbso0_XdijME=zDK9=5yKpi1a1NQM6j1qNczWbg@mail.gmail.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).