All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jiri Olsa <jolsa@kernel.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Andi Kleen <andi@firstfloor.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Vince Weaver <vince@deater.net>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 2/4] perf/x86: Fix period for non sampling events
Date: Tue, 3 Jan 2017 16:09:46 +0100	[thread overview]
Message-ID: <20170103150946.GX3107@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1482931866-6018-3-git-send-email-jolsa@kernel.org>

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?

>   - 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
	- 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).


Did your kernel include commit:

  daa864b8f8e3 ("perf/x86/pebs: Fix handling of PEBS buffer overflows")

?

  parent reply	other threads:[~2017-01-03 15:12 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   ` Peter Zijlstra [this message]
2017-01-03 15:26     ` [PATCH 2/4] perf/x86: Fix period for non sampling events Jiri Olsa
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=20170103150946.GX3107@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=vince@deater.net \
    --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.