linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kim Phillips <kim.phillips@amd.com>
To: Vijay Thakkar <vijaythakkar@me.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Martin Liška" <mliska@suse.cz>, "Jon Grimm" <jon.grimm@amd.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 3/3] perf vendor events amd: update Zen1 events to V2
Date: Wed, 15 Jan 2020 12:19:15 -0600	[thread overview]
Message-ID: <4411225b-1bb3-a273-bd74-7923f91006ff@amd.com> (raw)
In-Reply-To: <20191227125536.1091387-4-vijaythakkar@me.com>

On 12/27/19 6:55 AM, Vijay Thakkar wrote:

> [1]: Processor Programming Reference (PPR) for AMD Family 17h Models
> 01h,08h, Revision B2 Processors, 54945 Rev 3.03 - Jun 14, 2019.
> [2]: Processor Programming Reference (PPR) for AMD Family 17h Model 18h,
> Revision B1 Processors, 55570-B1 Rev 3.14 - Sep 26, 2019.

I'm a fan of providing links to the documents; saves reviewers some time searching for them.

> -  {
> -    "EventName": "ex_ret_cond_misp",
> -    "EventCode": "0xd2",
> -    "BriefDescription": "Retired Conditional Branch Instructions Mispredicted."
> -  },

Ack, this is in the 54945_PPR_Family_17h_Models_00h-0Fh document, which describes zen1, yet I get zeroes out of the hardware, which technically could mean that Zen has a 100% prediction rate, but I doubt it, given the workload I gave it was very unpredictable :)

> +    "EventName": "fpu_pipe_assignment.dual3",
> +    "EventCode": "0x00",
> +    "BriefDescription": "Total number multi-pipe uOps to pipe 3.",
> +    "PublicDescription": "The number of operations (uOps) and dual-pipe uOps dispatched to each of the 4 FPU execution pipelines. This event reflects how busy the FPU pipelines are and may be used for workload characterization. This includes all operations performed by x87, MMX, and SSE instructions, including moves. Each increment represents a one- cycle dispatch event. This event is a speculative event. Since this event includes non-numeric operations it is not suitable for measuring MFLOPS. Total number multi-pipe uOps assigned to Pipe 3.",
> +    "UMask": "0x8"
> +  },
> +  {
> +    "EventName": "fpu_pipe_assignment.dual2",
> +    "EventCode": "0x00",
> +    "BriefDescription": "Total number multi-pipe uOps to pipe 2.",
> +    "PublicDescription": "The number of operations (uOps) and dual-pipe uOps dispatched to each of the 4 FPU execution pipelines. This event reflects how busy the FPU pipelines are and may be used for workload characterization. This includes all operations performed by x87, MMX, and SSE instructions, including moves. Each increment represents a one- cycle dispatch event. This event is a speculative event. Since this event includes non-numeric operations it is not suitable for measuring MFLOPS. Total number multi-pipe uOps assigned to Pipe 3.",
> +    "UMask": "0x4"
> +  },
> +  {
> +    "EventName": "fpu_pipe_assignment.dual1",
> +    "EventCode": "0x00",
> +    "BriefDescription": "Total number multi-pipe uOps to pipe 1.",
> +    "PublicDescription": "The number of operations (uOps) and dual-pipe uOps dispatched to each of the 4 FPU execution pipelines. This event reflects how busy the FPU pipelines are and may be used for workload characterization. This includes all operations performed by x87, MMX, and SSE instructions, including moves. Each increment represents a one- cycle dispatch event. This event is a speculative event. Since this event includes non-numeric operations it is not suitable for measuring MFLOPS. Total number multi-pipe uOps assigned to Pipe 3.",
> +    "UMask": "0x2"
> +  },
> +  {
> +    "EventName": "fpu_pipe_assignment.dual0",
> +    "EventCode": "0x00",
> +    "BriefDescription": "Total number multi-pipe uOps to pipe 0.",
> +    "PublicDescription": "The number of operations (uOps) and dual-pipe uOps dispatched to each of the 4 FPU execution pipelines. This event reflects how busy the FPU pipelines are and may be used for workload characterization. This includes all operations performed by x87, MMX, and SSE instructions, including moves. Each increment represents a one- cycle dispatch event. This event is a speculative event. Since this event includes non-numeric operations it is not suitable for measuring MFLOPS. Total number multi-pipe uOps assigned to Pipe 3.",
> +    "UMask": "0x1"
> +  },

The UMasks for these .dualN event masks are wrong: they need to be left-shifted by 4 bits.

> +    "EventName": "ls_mab_alloc.loads",
> +    "EventCode": "0x41",
> +    "BriefDescription": "Data cache load miss.",
> +    "UMask": "0x40"

and this UMask should be 1.

This concludes my review of this version of this patchseries, sorry it took so long, and I didn't do a fully exhaustive review of #2 of 3.  If you post a v2 of the series, I'll be quicker to review that.

Thanks,

Kim

  reply	other threads:[~2020-01-15 18:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-27 12:55 [PATCH 0/3] perf vendor events amd: latest PMU events for zen1/zen2 Vijay Thakkar
2019-12-27 12:55 ` [PATCH 1/3] perf vendor events amd: restrict model detection for zen1 based processors Vijay Thakkar
2020-01-08 23:52   ` Kim Phillips
     [not found]     ` <20200112131021.GA5437@shwetrath.localdomain>
2020-01-14 23:07       ` Kim Phillips
2019-12-27 12:55 ` [PATCH 2/3] perf vendor events amd: add Zen2 events Vijay Thakkar
2020-01-14 23:15   ` Kim Phillips
2019-12-27 12:55 ` [PATCH 3/3] perf vendor events amd: update Zen1 events to V2 Vijay Thakkar
2020-01-15 18:19   ` Kim Phillips [this message]
2020-01-06 22:17 ` [PATCH 0/3] perf vendor events amd: latest PMU events for zen1/zen2 Arnaldo Carvalho de Melo
2020-01-07 17:46   ` Borislav Petkov

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=4411225b-1bb3-a273-bd74-7923f91006ff@amd.com \
    --to=kim.phillips@amd.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=jon.grimm@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mliska@suse.cz \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=vijaythakkar@me.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).