From: Jiri Olsa <email@example.com> To: Peter Zijlstra <firstname.lastname@example.org> Cc: Jiri Olsa <email@example.com>, lkml <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Andi Kleen <firstname.lastname@example.org>, Alexander Shishkin <email@example.com>, Arnaldo Carvalho de Melo <firstname.lastname@example.org>, Vince Weaver <email@example.com>, Stephane Eranian <firstname.lastname@example.org> Subject: Re: [PATCH 2/4] perf/x86: Fix period for non sampling events Date: Tue, 3 Jan 2017 16:26:00 +0100 [thread overview] Message-ID: <20170103152600.GA8826@krava> (raw) In-Reply-To: <20170103150946.GX3107@twins.programming.kicks-ass.net> On Tue, Jan 03, 2017 at 04:09:46PM +0100, Peter Zijlstra wrote: > On Wed, Dec 28, 2016 at 02:31:04PM +0100, Jiri Olsa wrote: > > When in counting mode we setup the counter with the > > longest possible period and read the value with read > > syscall. > > > > We also still setup the PMI to be triggered when such > > counter overflow to reconfigure it. > > > > We also get PEBS interrupt if such counter has precise_ip > > set (which makes no sense, but it's possible). > > > > Having such counter with: > > - counting mode > > - precise_ip set > > > > I watched my server to get stuck serving PEBS interrupt > > again and again because of following (AFAICS): > > > > - PEBS interrupt is triggered before PMI > > Slightly confused, the PEBS interrupt _is_ the PMI. And how can we get > an interrupt before the counter overflows? > > > - when PEBS handling path reconfigured counter it > > had remaining value of -256 > > You're talking about the actual counter value, right, not @left? right > > > - the x86_perf_event_set_period does not consider this > > as an extreme value, so it's configured back as the > > new counter value > > Right, a counter value of -256 would result in @left being 256 which is > positive and not too large, so we 'retain' the value. > > > - this makes the PEBS interrupt to be triggered right > > away again > > So I'm curious how this is even possible. The normal described way of > things is: > > - we program the counter with a negative value > - each 'event' does a counter increment > - if we 'overflow' (turn positive) we start to arm the PEBS > assist heh, I guess I thought this could happen earlier ;-) otherwise I dont get how could I saw -256 left in the counter value.. > - once the assist is armed, the next 'event' triggers a PEBS > record. > - if the amount of PEBS records exceeds the DS threshold, we > set bit 62 in GLOBAL_STATUS and raise the PMI. > > At which point the actual counter value should be at the very least 1 > (for having counted the event that triggers the PEBS assist into > creating the record). what I saw was the bit 62 set and pebs_drain->__intel_pmu_pebs_event re-configuring the event back with -256 again and again.. I'll run fuzzer again without the fix with my debug stuff in and try to recreate ;-) > Did your kernel include commit: > > daa864b8f8e3 ("perf/x86/pebs: Fix handling of PEBS buffer overflows") yep jirka
next prev parent reply other threads:[~2017-01-03 15:27 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-28 13:31 [PATCH 0/4] perf: Fuzzer fixes Jiri Olsa 2016-12-28 13:31 ` [PATCH 1/4] perf/x86/intel: Account interrupts for PEBS errors Jiri Olsa 2017-01-14 12:29 ` [tip:perf/urgent] " tip-bot for Jiri Olsa 2016-12-28 13:31 ` [PATCH 2/4] perf/x86: Fix period for non sampling events Jiri Olsa 2017-01-03 9:40 ` Peter Zijlstra 2017-01-03 14:24 ` [PATCH] perf/x86: Reject non sampling events with precise_ip Jiri Olsa 2017-01-03 22:06 ` Vince Weaver 2017-01-14 12:29 ` [tip:perf/urgent] " tip-bot for Jiri Olsa 2017-01-03 15:09 ` [PATCH 2/4] perf/x86: Fix period for non sampling events Peter Zijlstra 2017-01-03 15:26 ` Jiri Olsa [this message] 2016-12-28 13:31 ` [PATCH 3/4] perf: Add perf_event_overflow_throttle function Jiri Olsa 2016-12-28 13:31 ` [PATCH 4/4] perf/x86/intel: Throttle PEBS events only from pmi Jiri Olsa 2017-01-03 13:45 ` Peter Zijlstra 2017-01-24 16:41 ` Peter Zijlstra 2017-01-25 13:02 ` Jiri Olsa 2017-01-25 13:02 ` Jiri Olsa
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=20170103152600.GA8826@krava \ --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: [PATCH 2/4] perf/x86: Fix period for non sampling events' \ /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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.