All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
	rnsastry@linux.ibm.com, kajoljain <kjain@linux.ibm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/2] powerpc/perf: Expose instruction and data address registers as part of extended regs
Date: Mon, 20 Sep 2021 17:13:17 +1000	[thread overview]
Message-ID: <87ilyviusy.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <38CCAAE2-A157-4689-B774-43FC48883699@linux.vnet.ibm.com>

Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
>> On 08-Sep-2021, at 10:47 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> 
>> Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
>>> Patch adds support to include Sampled Instruction Address Register
>>> (SIAR) and Sampled Data Address Register (SDAR) SPRs as part of extended
>>> registers. Update the definition of PERF_REG_PMU_MASK_300/31 and
>>> PERF_REG_EXTENDED_MAX to include these SPR's.
>>> 
>>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>>> ---
>>> arch/powerpc/include/uapi/asm/perf_regs.h | 12 +++++++-----
>>> arch/powerpc/perf/perf_regs.c             |  4 ++++
>>> 2 files changed, 11 insertions(+), 5 deletions(-)
>>> 
>> ...
>>> diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
>>> index b931eed..51d31b6 100644
>>> --- a/arch/powerpc/perf/perf_regs.c
>>> +++ b/arch/powerpc/perf/perf_regs.c
>>> @@ -90,7 +90,11 @@ static u64 get_ext_regs_value(int idx)
>>> 		return mfspr(SPRN_SIER2);
>>> 	case PERF_REG_POWERPC_SIER3:
>>> 		return mfspr(SPRN_SIER3);
>>> +	case PERF_REG_POWERPC_SDAR:
>>> +		return mfspr(SPRN_SDAR);
>>> #endif
>>> +	case PERF_REG_POWERPC_SIAR:
>>> +		return mfspr(SPRN_SIAR);
>>> 	default: return 0;
>>> 	}
>> 
>> This file is built for all powerpc configs that have PERF_EVENTS. Which
>> includes CPUs that don't have SDAR or SIAR.
>> 
>> Don't we need checks in perf_reg_value() like we do for SIER?
>
> Hi Michael,
>
> Thanks for the review.
>
> SIER is part of PERF_REG_PMU_MASK and hence check is needed to see if platform supports SIER.
> Incase of extended regs, they are part of PERF_REG_EXTENDED_MASK and this mask is
> filled with supported registers while registering the PMU ( ie during init_power9/10_pmu ). So these registers will be added
> only for supported platforms. The validity of extended mask is also done in PMU common code 
> ( In kernel/events/core.c with PERF_REG_EXTENDED_MASK check ). So an unsupported platform requesting for extended
> registers won’t get it.

Right, I'd forgotten how that works.

But I think part of the reason I didn't remember is that
PERF_REG_PMU_MASK_31 doesn't mention those regs by name, it's just a hex
constant, ie:

-#define PERF_REG_PMU_MASK_31   (0xfffULL << PERF_REG_POWERPC_MMCR0)
+#define PERF_REG_PMU_MASK_31   (0x3fffULL << PERF_REG_POWERPC_MMCR0)

Presumably you tested that the added 0x3 there sets the right bits for
SDAR and SIAR, but it's 1) not obvious and 2) fragile.

So I'd like it better if we constructed the PERF_REG_PMU_MASK_31, and
other similar masks, by or'ing together the actual register value
constants.

eg. something like:

#define PERF_REG_PMU_MASK_31	\
	((1ul << PERF_REG_POWERPC_MMCR0) | (1ul << PERF_REG_POWERPC_MMCR1) | \
	(1ul << PERF_REG_POWERPC_MMCR2) | (1ul << PERF_REG_POWERPC_MMCR3) | \
	(1ul << PERF_REG_POWERPC_SIER2) | (1ul << PERF_REG_POWERPC_SIER3) | \
	(1ul << PERF_REG_POWERPC_PMC1) | (1ul << PERF_REG_POWERPC_PMC2) | \
	(1ul << PERF_REG_POWERPC_PMC3) | (1ul << PERF_REG_POWERPC_PMC4) | \
	(1ul << PERF_REG_POWERPC_PMC5) | (1ul << PERF_REG_POWERPC_PMC6))


Also PERF_REG_EXTENDED_MAX should be part of the enum, just like
PERF_REG_POWERPC_MAX.

cheers

  reply	other threads:[~2021-09-20  7:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-20 14:45 [PATCH 0/2] powerpc/perf: Add instruction and data address registers to extended regs Athira Rajeev
2021-06-20 14:45 ` [PATCH 1/2] powerpc/perf: Expose instruction and data address registers as part of " Athira Rajeev
2021-09-08  5:17   ` Michael Ellerman
2021-09-09  2:48     ` Athira Rajeev
2021-09-20  7:13       ` Michael Ellerman [this message]
2021-09-21  3:01         ` Athira Rajeev
2021-06-20 14:46 ` [PATCH 2/2] tools/perf: Add perf tools support to expose " Athira Rajeev
2021-06-21  4:09 ` [PATCH 0/2] powerpc/perf: Add instruction and data address registers to " Nageswara Sastry
2021-09-02  7:34 ` kajoljain
2021-09-06  2:43   ` Athira Rajeev
2021-09-11 19:09     ` Arnaldo Carvalho de Melo
2021-09-20  6:54       ` Michael Ellerman

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=87ilyviusy.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=acme@kernel.org \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=jolsa@kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=rnsastry@linux.ibm.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.