linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Rob Herring <robh@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-perf-users@vger.kernel.org
Subject: Re: [RFC V1 03/11] arm64/perf: Update struct arm_pmu for BRBE
Date: Fri, 28 Jan 2022 09:08:20 +0530	[thread overview]
Message-ID: <c3804290-bdb1-d1eb-3526-9b0ce4c8e8b1@arm.com> (raw)
In-Reply-To: <YfF+APV2vew5AloE@robh.at.kernel.org>



On 1/26/22 10:29 PM, Rob Herring wrote:
> On Mon, Jan 24, 2022 at 10:00:45AM +0530, Anshuman Khandual wrote:
>> This updates struct arm_pmu to include all required helpers that will drive
> 
>>From submitting-patches.rst:
> 
> Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
> instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
> to do frotz", as if you are giving orders to the codebase to change
> its behaviour.

s/This updates struct arm_pmu to/Update struct arm_pmu to/ should address
this problem I guess. Although the difference here seems very subtle :)

> 
>> BRBE functionality for a given PMU implementation. These are the following.
> 
> Don't describe what the change is, one can read the diff for that. 

Sure, though was trying just to enumerate a potential driver's functional
responsibilities.

> Answer why it is needed.

Sure.

> 
> One thing to answer in the commit msg is why we need the hooks here.  
> Have we concluded that adding BRBE hooks to struct arm_pmu for what is 
> an armv8 specific feature is the right approach? I don't recall 
> reaching that conclusion.

Although it might be possible to have this implementation embedded in
the existing armv8 PMU implementation, I still believe that the BRBE
functionalities abstracted out at the arm_pmu level with a separate
config option is cleaner, easier to follow and to maintain as well.

Besides some helpers i.e brbe_supported(), brbe_probe() and brbe_reset()
might not fit seamlessly, when tried to be embedded via existing arm_pmu
helpers in the armv8 implementation.

Nonetheless if arm_pmu based additional BRBE helpers is absolutely a no
go for folks here in general, will explore arm64 based implementation.

> 
>>
>> - brbe_filter	: Convert perf event filters into BRBE HW filters
>> - brbe_probe	: Probe BRBE HW and capture its attributes
>> - brbe_enable	: Enable BRBE HW with a given config
>> - brbe_disable	: Disable BRBE HW
>> - brbe_read	: Read BRBE buffer for captured branch records
>> - brbe_reset	: Reset BRBE buffer
>> - brbe_supported: Whether BRBE is supported or not
> 
> The function names seem pretty self-explanatory, but the text is needed, 
> shouldn't it be in the struct declaration.

Sure, sounds good. Will move there.

> 
> I'm not really a fan of patches adding dead code. That's not any less to 
> review. Restructuring with 'no functional change' OTOH is helpful in 
> reviewing.

Restructuring without functional change clarifies the purpose better.
Besides this is more relevant in this context where the functions will
be provided by a separate (and also detached) driver implementation.

>> A BRBE driver implementation needs to provide these functionalities.
>>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-perf-users@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>  arch/arm64/kernel/perf_event.c | 36 ++++++++++++++++++++++++++++++++++
>>  include/linux/perf/arm_pmu.h   |  7 +++++++
>>  2 files changed, 43 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index cab678ed6618..f6a47036b0b4 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -1015,6 +1015,35 @@ static int armv8pmu_filter_match(struct perf_event *event)
>>  	return evtype != ARMV8_PMUV3_PERFCTR_CHAIN;
>>  }
>>  
>> +static void armv8pmu_brbe_filter(struct pmu_hw_events *hw_event, struct perf_event *event)
>> +{
>> +}
>> +
>> +static void armv8pmu_brbe_enable(struct pmu_hw_events *hw_event)
>> +{
>> +}
>> +
>> +static void armv8pmu_brbe_disable(struct pmu_hw_events *hw_event)
>> +{
>> +}
>> +
>> +static void armv8pmu_brbe_read(struct pmu_hw_events *hw_event, struct perf_event *event)
>> +{
>> +}
>> +
>> +static void armv8pmu_brbe_probe(struct pmu_hw_events *hw_event)
>> +{
>> +}
>> +
>> +static void armv8pmu_brbe_reset(struct pmu_hw_events *hw_event)
>> +{
>> +}
>> +
>> +static bool armv8pmu_brbe_supported(struct perf_event *event)
>> +{
>> +	return false;
>> +}
>> +
>>  static void armv8pmu_reset(void *info)
>>  {
>>  	struct arm_pmu *cpu_pmu = (struct arm_pmu *)info;
>> @@ -1247,6 +1276,13 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char *name,
>>  
>>  	cpu_pmu->pmu.event_idx		= armv8pmu_user_event_idx;
>>  
>> +	cpu_pmu->brbe_filter		= armv8pmu_brbe_filter;
>> +	cpu_pmu->brbe_enable		= armv8pmu_brbe_enable;
>> +	cpu_pmu->brbe_disable		= armv8pmu_brbe_disable;
>> +	cpu_pmu->brbe_read		= armv8pmu_brbe_read;
>> +	cpu_pmu->brbe_probe		= armv8pmu_brbe_probe;
>> +	cpu_pmu->brbe_reset		= armv8pmu_brbe_reset;
>> +	cpu_pmu->brbe_supported		= armv8pmu_brbe_supported;
>>  	cpu_pmu->name			= name;
>>  	cpu_pmu->map_event		= map_event;
>>  	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] = events ?
>> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
>> index 2512e2f9cd4e..c0dd0d6c5883 100644
>> --- a/include/linux/perf/arm_pmu.h
>> +++ b/include/linux/perf/arm_pmu.h
>> @@ -98,6 +98,13 @@ struct arm_pmu {
>>  	void		(*reset)(void *);
>>  	int		(*map_event)(struct perf_event *event);
>>  	int		(*filter_match)(struct perf_event *event);
>> +	void		(*brbe_filter)(struct pmu_hw_events *hw_events, struct perf_event *event);
>> +	void		(*brbe_probe)(struct pmu_hw_events *hw_events);
>> +	void		(*brbe_enable)(struct pmu_hw_events *hw_events);
>> +	void		(*brbe_disable)(struct pmu_hw_events *hw_events);
>> +	void		(*brbe_read)(struct pmu_hw_events *hw_events, struct perf_event *event);
>> +	void		(*brbe_reset)(struct pmu_hw_events *hw_events);
>> +	bool		(*brbe_supported)(struct perf_event *event);
>>  	int		num_events;
>>  	bool		secure_access; /* 32-bit ARM only */
>>  #define ARMV8_PMUV3_MAX_COMMON_EVENTS		0x40
>> -- 
>> 2.25.1
>>
>>

  reply	other threads:[~2022-01-28  3:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24  4:30 [RFC V1 00/11] arm64/perf: Enable branch stack sampling Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 01/11] perf: Consolidate branch sample filter helpers Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 02/11] arm64/perf: Add register definitions for BRBE Anshuman Khandual
2022-01-24 14:05   ` Marc Zyngier
2022-01-25  5:04     ` Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 03/11] arm64/perf: Update struct arm_pmu " Anshuman Khandual
2022-01-26 16:59   ` Rob Herring
2022-01-28  3:38     ` Anshuman Khandual [this message]
2022-01-24  4:30 ` [RFC V1 04/11] arm64/perf: Update struct pmu_hw_events " Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 05/11] arm64/perf: Detect support " Anshuman Khandual
2022-01-26 17:18   ` Rob Herring
2022-01-28  3:27     ` Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 06/11] arm64/perf: Drive BRBE from perf event states Anshuman Khandual
2022-01-26 17:07   ` Rob Herring
2022-01-27 12:20     ` Anshuman Khandual
2022-01-27 14:31       ` Rob Herring
2022-01-24  4:30 ` [RFC V1 07/11] arm64/perf: Add BRBE driver Anshuman Khandual
2022-01-24 18:11   ` James Clark
2022-01-24 18:15   ` James Clark
2022-01-24  4:30 ` [RFC V1 08/11] arm64/perf: Enable branch stack sampling Anshuman Khandual
2022-01-24 18:02   ` James Clark
2022-01-24  4:30 ` [RFC V1 09/11] perf: Add more generic branch types Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 10/11] perf: Expand perf_branch_entry.type Anshuman Khandual
2022-01-25 16:58   ` James Clark
2022-01-28  4:14     ` Anshuman Khandual
2022-01-26 16:47   ` Rob Herring
2022-01-27 10:41     ` Anshuman Khandual
2022-01-24  4:30 ` [RFC V1 11/11] perf: Capture branch privilege information Anshuman Khandual
2022-01-25 15:39   ` James Clark
2022-02-02 11:11     ` Anshuman Khandual
2022-01-26 17:27   ` James Clark
2022-03-14  6:47     ` Anshuman Khandual
2022-01-25 16:25 ` [PATCH 0/1] perf test: Add branch stack sampling tests for ARM64 German Gomez
2022-01-25 16:25   ` [PATCH 1/1] " German Gomez

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=c3804290-bdb1-d1eb-3526-9b0ce4c8e8b1@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=acme@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=robh@kernel.org \
    --cc=will@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;
as well as URLs for NNTP newsgroup(s).