* perf: rdpmc and PERF_EVENT_IOC_RESET
@ 2016-08-17 4:53 Vince Weaver
2016-08-17 15:26 ` Peter Zijlstra
0 siblings, 1 reply; 3+ messages in thread
From: Vince Weaver @ 2016-08-17 4:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Ingo Molnar, Peter Zijlstra, Arnaldo Carvalho de Melo
Hello
so using rdpmc() and the mmap page to do fast perf_event reads seems to
interact poorly with the PERF_EVENT_IOC_RESET ioctl.
>From what I can tell, on reset event->count is set to zero, but
event->hw.prev_count is not, so the userpg->offset field ends up negative
and weird things happen.
Shout reset just not be called if you are using the rdpmc() interface?
Vince
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: perf: rdpmc and PERF_EVENT_IOC_RESET 2016-08-17 4:53 perf: rdpmc and PERF_EVENT_IOC_RESET Vince Weaver @ 2016-08-17 15:26 ` Peter Zijlstra 2016-08-18 4:32 ` Vince Weaver 0 siblings, 1 reply; 3+ messages in thread From: Peter Zijlstra @ 2016-08-17 15:26 UTC (permalink / raw) To: Vince Weaver; +Cc: linux-kernel, Ingo Molnar, Arnaldo Carvalho de Melo On Wed, Aug 17, 2016 at 12:53:01AM -0400, Vince Weaver wrote: > Hello > > so using rdpmc() and the mmap page to do fast perf_event reads seems to > interact poorly with the PERF_EVENT_IOC_RESET ioctl. Hurm.. I never considered using RESET with rdpmc(). The typical usage of rdpmc() I considered is something like: u64 start = rdpmc(); /* code goes here */ delta = rdpmc() - start; That said; I don't object to fixing the interaction if it doesn't have downsides. > From what I can tell, on reset event->count is set to zero, but > event->hw.prev_count is not, so the userpg->offset field ends up negative > and weird things happen. _perf_event_reset() perf_event_read() /* updates prev_count */ local64_set(count, 0); after that, like you say: userpg->offset = perf_event_count() - prev_count, which does indeed end up negative. But the rdpmc user function should: u64 mmap_read_self(void *addr) { struct perf_event_mmap_page *pc = addr; u32 seq, idx, time_mult = 0, time_shift = 0, width = 0; u64 count, cyc = 0, time_offset = 0, enabled, running, delta; s64 pmc = 0; do { seq = pc->lock; barrier(); /* enabled/running muck */ idx = pc->index; count = pc->offset; if (pc->cap_user_rdpmc && idx) { width = pc->pmc_width; pmc = rdpmc(idx - 1); } barrier(); } while (pc->lock != seq); if (idx) { pmc <<= 64 - width; pmc >>= 64 - width; /* shift right signed */ count += pmc; } /* more enabled/running muck */ return count; } Which sign-extends the RDPMC result and adds it to userpg->offset, resulting in a positive number again. So I think it should work.. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: perf: rdpmc and PERF_EVENT_IOC_RESET 2016-08-17 15:26 ` Peter Zijlstra @ 2016-08-18 4:32 ` Vince Weaver 0 siblings, 0 replies; 3+ messages in thread From: Vince Weaver @ 2016-08-18 4:32 UTC (permalink / raw) To: Peter Zijlstra; +Cc: linux-kernel, Ingo Molnar, Arnaldo Carvalho de Melo On Wed, 17 Aug 2016, Peter Zijlstra wrote: > Hurm.. I never considered using RESET with rdpmc(). The typical usage of > rdpmc() I considered is something like: I'm finally trying to hook up PAPI to properly use rdpmc and PAPI likes to use IOC_RESET in various places. I can just special case to not do so when in rdpmc mode, but I got curious if RESET was expected to work. > But the rdpmc user function should: > ... > > Which sign-extends the RDPMC result and adds it to userpg->offset, > resulting in a positive number again. I will have to check to see if PAPI is using the proper code. What happens is the procesed result has bit 49 set for some reason, so the results are 2^49 too big. I've been trying to track it down, but the PAPI code is a bit of a mess (to put it mildly). Vince ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-08-18 4:32 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-17 4:53 perf: rdpmc and PERF_EVENT_IOC_RESET Vince Weaver 2016-08-17 15:26 ` Peter Zijlstra 2016-08-18 4:32 ` Vince Weaver
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®