All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@intel.com
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
	eranian@google.com, alexander.shishkin@linux.intel.com,
	ak@linux.intel.com, lukasz.odzioba@intel.com
Subject: Re: [PATCH] perf/x86: fix event counter update issue
Date: Tue, 29 Nov 2016 10:25:20 +0100	[thread overview]
Message-ID: <20161129092520.GB3092@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1480361206-1702-1-git-send-email-kan.liang@intel.com>


So caveat that I'm ill and cannot think much..

On Mon, Nov 28, 2016 at 11:26:46AM -0800, kan.liang@intel.com wrote:

> Here, all the possible failure cases are listed.
> Terms:
>     - new: current PMU counter value which read from rdpmcl.
>     - prev: previous counter value which is stored in &hwc->prev_count.
>     - in PMI/not in PMI: the event update happens in PMI handler or not.

> Current code to calculate delta:
>     delta = (new << shift) - (prev << shift);
>     delta >>= shift;
> 
> Case A: Not in PMI.  new > prev. But delta is negative.
>    That's the failure case of Test 2.
>    delta is s64 type. new and prev are u64 type. If the new is big
>    enough, after doing left shift and sub, the bit 64 of the result may
>    still be 1.
>    After converting to s64, the sign flag will be set. Since delta is
>    s64 type, arithmetic right shift is applied, which copy the sign flag
>    into empty bit positions on the upper end of delta.
>    It can be fixed by adding the max count value.
> 
>    Here is the real data for test2 on KNL.
>    new = aea96e1927
>    prev = ffffff0000000001
>    delta = aea96e1927000000 - 1000000 = aea96e1926000000
>    aea96e1926000000 >> 24 = ffffffaea96e1926   <<  negative delta

How can this happen? IIRC the thing increments, we program a negative
value, and when it passes 0 we generate a PMI.

And note that we _ALWAYS_ set the IN bits, even for !sampling events.
Also note we set max_period to (1<<31) - 1, so we should never exceed 31
bits.


> Case B: In PMI. new > prev. delta is positive.
>    That's the failure case of Test 3.
>    The PMI is triggered by overflow. But there is latency between
>    overflow and PMI handler. So new has small amount.
>    Current calculation lose the max count value.

That doesn't make sense, per the 31bit limit.


> Case C: In PMI. new < prev. delta is negative.
>    The PMU counter may be start from a big value. E.g. the fixed period
>    is small.
>    It can be fixed by adding the max count value.

Doesn't make sense, how can this happen?

  parent reply	other threads:[~2016-11-29  9:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28 19:26 [PATCH] perf/x86: fix event counter update issue kan.liang
2016-11-28 19:41 ` Stephane Eranian
2016-11-28 19:59   ` Liang, Kan
2016-11-28 20:18     ` Stephane Eranian
2016-11-28 20:23       ` Liang, Kan
2016-11-29  9:25 ` Peter Zijlstra [this message]
2016-11-29 14:46   ` Liang, Kan
2016-11-29 16:58     ` Peter Zijlstra
2016-11-29 17:06       ` Liang, Kan
2016-11-29 17:17         ` Peter Zijlstra
2016-11-29 17:20   ` Stephane Eranian
2016-11-29 17:30     ` Peter Zijlstra
2016-11-29 18:11       ` Stephane Eranian
2016-11-29 18:37       ` Andi Kleen
2016-11-29 19:07       ` Liang, Kan
2016-11-29 19:32         ` Peter Zijlstra
2016-11-29 20:33           ` Liang, Kan
2016-11-29 20:37             ` Stephane Eranian
2016-12-02 12:58             ` Odzioba, Lukasz
2016-12-05 10:25               ` Peter Zijlstra
2016-12-05 11:21                 ` Odzioba, Lukasz
2017-02-22 14:49                 ` Vince Weaver
2017-02-22 15:28                   ` Liang, Kan
2017-02-22 19:18                     ` Andi Kleen
2017-02-23 15:07                     ` Vince Weaver
2017-02-23 16:14                       ` Liang, Kan
2016-11-29 19:08     ` Odzioba, Lukasz

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=20161129092520.GB3092@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz.odzioba@intel.com \
    --cc=mingo@redhat.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.