From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759136AbdACP1Z (ORCPT ); Tue, 3 Jan 2017 10:27:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42744 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759034AbdACP0E (ORCPT ); Tue, 3 Jan 2017 10:26:04 -0500 Date: Tue, 3 Jan 2017 16:26:00 +0100 From: Jiri Olsa To: Peter Zijlstra Cc: Jiri Olsa , lkml , Ingo Molnar , Andi Kleen , Alexander Shishkin , Arnaldo Carvalho de Melo , Vince Weaver , Stephane Eranian Subject: Re: [PATCH 2/4] perf/x86: Fix period for non sampling events Message-ID: <20170103152600.GA8826@krava> References: <1482931866-6018-1-git-send-email-jolsa@kernel.org> <1482931866-6018-3-git-send-email-jolsa@kernel.org> <20170103150946.GX3107@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103150946.GX3107@twins.programming.kicks-ass.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 03 Jan 2017 15:26:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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