public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: peterz@infradead.org
To: Kim Phillips <kim.phillips@amd.com>
Cc: Borislav Petkov <bp@alien8.de>, Borislav Petkov <bp@suse.de>,
	Ingo Molnar <mingo@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephane Eranian <eranian@google.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Jiri Olsa <jolsa@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Michael Petlan <mpetlan@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
	Stephane Eranian <stephane.eranian@google.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 3/7] arch/x86/amd/ibs: Fix re-arming IBS Fetch
Date: Thu, 10 Sep 2020 10:32:23 +0200	[thread overview]
Message-ID: <20200910083223.GY1362448@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200908214740.18097-4-kim.phillips@amd.com>

On Tue, Sep 08, 2020 at 04:47:36PM -0500, Kim Phillips wrote:
> Stephane Eranian found a bug in that IBS' current Fetch counter was not
> being reset when the driver would write the new value to clear it along
> with the enable bit set, and found that adding an MSR write that would
> first disable IBS Fetch would make IBS Fetch reset its current count.
> 
> Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12,
> 2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when
> IbsFetchEn is changed from 0 to 1."
> 
> Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch,
> so the driver properly resets the internal counter to 0 and IBS
> Fetch starts counting again.
> 
> A family 15h machine tested does not have this problem, and the extra
> wrmsr is also not needed on Family 19h, so only do the extra wrmsr on
> families 16h through 18h.

*groan*...

> ---
>  arch/x86/events/amd/ibs.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
> index 26c36357c4c9..3eb9a55e998c 100644
> --- a/arch/x86/events/amd/ibs.c
> +++ b/arch/x86/events/amd/ibs.c
> @@ -363,7 +363,14 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct perf_event *event,
>  static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
>  					 struct hw_perf_event *hwc, u64 config)
>  {
> -	wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
> +	u64 _config = (hwc->config | config) & ~perf_ibs->enable_mask;
> +
> +	/* On Fam17h, the periodic fetch counter is set when IbsFetchEn is changed from 0 to 1 */
> +	if (perf_ibs == &perf_ibs_fetch && boot_cpu_data.x86 >= 0x16 && boot_cpu_data.x86 <= 0x18)
> +		wrmsrl(hwc->config_base, _config);

That's an anti-patttern (and for some reason this is the second time in
a week I've seen it). This is a fairly hot path and you're adding a
whole bunch of loads and branches.

Granted, in case you need the extra wrmsr that's probably noise, but
supposedly you're going to be fixing this in hardware eventually, and
you'll be getting rid of the second wrmsr again. But then you're stuck
with the loads and branches.

A better option would be to use hwc->flags, you're loading from that
line already, so it's guaranteed hot and then you only have a single
branch. Or stick it in perf_ibs near enable_mask, same difference.

> + 	_config |= perf_ibs->enable_mask;
> +	wrmsrl(hwc->config_base, _config);
>  }
>  
>  /*
> -- 
> 2.27.0
> 

  reply	other threads:[~2020-09-10  8:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 21:47 [PATCH v2 0/7] perf/x86/amd: Miscellaneous updates Kim Phillips
2020-09-08 21:47 ` [PATCH v2 1/7] perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour Kim Phillips
2020-09-10 16:34   ` Sasha Levin
2020-09-11  7:02   ` [tip: perf/core] " tip-bot2 for Kim Phillips
2020-09-08 21:47 ` [PATCH v2 2/7] perf/x86/amd: Fix sampling Large Increment per Cycle events Kim Phillips
2020-09-08 21:47 ` [PATCH v2 3/7] arch/x86/amd/ibs: Fix re-arming IBS Fetch Kim Phillips
2020-09-10  8:32   ` peterz [this message]
2020-09-10  8:50     ` peterz
2020-09-10 15:58       ` Kim Phillips
2020-09-08 21:47 ` [PATCH v2 4/7] perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count() Kim Phillips
2020-09-08 21:47 ` [PATCH v2 5/7] perf/x86/amd/ibs: Fix raw sample data accumulation Kim Phillips
2020-09-11  7:02   ` [tip: perf/core] " tip-bot2 for Kim Phillips
2020-09-08 21:47 ` [PATCH v2 6/7] perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter Kim Phillips
2020-09-11  7:02   ` [tip: perf/core] " tip-bot2 for Kim Phillips
2020-09-08 21:47 ` [PATCH v2 7/7] perf/x86/rapl: Add AMD Fam19h RAPL support Kim Phillips
2020-09-11  7:02   ` [tip: perf/core] " tip-bot2 for Kim Phillips

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=20200910083223.GY1362448@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=kim.phillips@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stephane.eranian@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox