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 06/11] arm64/perf: Drive BRBE from perf event states
Date: Thu, 27 Jan 2022 17:50:54 +0530	[thread overview]
Message-ID: <9e56509a-2772-a333-ccc3-ad49a2028616@arm.com> (raw)
In-Reply-To: <YfF/zBS3kL/+eC1k@robh.at.kernel.org>


On 1/26/22 10:37 PM, Rob Herring wrote:
> On Mon, Jan 24, 2022 at 10:00:48AM +0530, Anshuman Khandual wrote:
>> Branch stack sampling rides along the normal perf event and all the branch
>> records get captured during the PMU interrupt. This just changes perf event
>> handling on the arm64 platform to accommodate required BRBE operations that
>> will enable branch stack sampling support.
>>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: linux-perf-users@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>  arch/arm64/kernel/perf_event.c |  6 +++++
>>  drivers/perf/arm_pmu.c         | 40 ++++++++++++++++++++++++++++++++++
>>  2 files changed, 46 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index f6a47036b0b4..11c82c8f2eec 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -864,6 +864,12 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
>>  		if (!armpmu_event_set_period(event))
>>  			continue;
>>  
>> +		if (has_branch_stack(event)) {
>> +			cpu_pmu->brbe_read(cpuc, event);
> 
> Is has_branch_stack() guaranteed to be false on arm32? If not, this will 
> be a NULL function ptr.

armpmu_event_init() blocks a perf event from being created with branch
stack sampling request without CONFIG_ARM_BRBE_PMU option being enabled
first, which has dependency on CONFIG_ARM64. So has_branch_stack() is
guaranteed to be false on arm32.

static int armpmu_event_init(struct perf_event *event)
{
	....
        if (has_branch_stack(event)) {
                /*
                 * BRBE support is absent. Select CONFIG_ARM_BRBE_PMU
                 * in the config, before branch stack sampling events
                 * can be requested.
                 */
                if (!IS_ENABLED(CONFIG_ARM_BRBE_PMU)) {
                        pr_warn_once("BRBE is disabled, select CONFIG_ARM_BRBE_PMU\n");
                        return -EOPNOTSUPP;
                }


config ARM_BRBE_PMU
        tristate "Enable support for Branch Record Buffer Extension (BRBE)"
        depends on ARM64 && ARM_PMU
        default y
        help
          Enable perf support for Branch Record Buffer Extension (BRBE) which
          records all branches taken in an execution path. This supports some
          branch types and privilege based filtering. It captured additional
          relevant information such as cycle count, misprediction and branch
          type, branch privilege level etc.

> 
> To add to my other comments, this patch is where I would add 
> brbe_read(), etc. to arm_pmu.

Because all new arm_pmu helpers get added and get used in the perf driver
in the same patch, although the actual helper implementation would still
come by bit later via the driver. This also uses updates to pmu_hw_events
struct as well, then that patch needs to be folded here as well.

There is no problem as such, kind of bit subjective. I just feel inclined
to keep the independent infrastructure changes separate making it easy to
review while also creating a flow.

  reply	other threads:[~2022-01-27 12:20 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
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 [this message]
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=9e56509a-2772-a333-ccc3-ad49a2028616@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).