From: Ilkka Koskinen <ilkka@os.amperecomputing.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ilkka Koskinen <ilkka@os.amperecomputing.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: arm_pmuv3: Use BR_RETIRED for HW branch event if enabled
Date: Fri, 6 Sep 2024 11:28:03 -0700 (PDT) [thread overview]
Message-ID: <ea7ff9b-b91c-d158-dfde-4569784a4720@os.amperecomputing.com> (raw)
In-Reply-To: <f632d5c8-93db-402c-82ec-9f3b79906458@arm.com>
On Fri, 6 Sep 2024, Anshuman Khandual wrote:
> On 9/6/24 02:17, Ilkka Koskinen wrote:
>> The PMU driver attempts to use PC_WRITE_RETIRED for the HW branch event,
>> if enabled. However, PC_WRITE_RETIRED counts only taken branches,
>> whereas BR_RETIRED counts also non-taken ones.
>>
>> Furthermore, perf uses HW branch event to calculate branch misses ratio,
>> implying BR_RETIRED is the correct event to count.
> But is the event BR_RETIRED always guaranteed to be available. Should not
> armpmu->pmceid_bitmap be checked first ?
>
>>
>> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
>> ---
>> drivers/perf/arm_pmuv3.c | 27 ++++-----------------------
>> 1 file changed, 4 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
>> index d246840797b6..a8ed08df1411 100644
>> --- a/drivers/perf/arm_pmuv3.c
>> +++ b/drivers/perf/arm_pmuv3.c
>> @@ -46,6 +46,7 @@ static const unsigned armv8_pmuv3_perf_map[PERF_COUNT_HW_MAX] = {
>> [PERF_COUNT_HW_INSTRUCTIONS] = ARMV8_PMUV3_PERFCTR_INST_RETIRED,
>> [PERF_COUNT_HW_CACHE_REFERENCES] = ARMV8_PMUV3_PERFCTR_L1D_CACHE,
>> [PERF_COUNT_HW_CACHE_MISSES] = ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL,
>> + [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = ARMV8_PMUV3_PERFCTR_BR_RETIRED,
>> [PERF_COUNT_HW_BRANCH_MISSES] = ARMV8_PMUV3_PERFCTR_BR_MIS_PRED,
>> [PERF_COUNT_HW_BUS_CYCLES] = ARMV8_PMUV3_PERFCTR_BUS_CYCLES,
>> [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV8_PMUV3_PERFCTR_STALL_FRONTEND,
>> @@ -1083,28 +1084,6 @@ static void armv8pmu_reset(void *info)
>> armv8pmu_pmcr_write(pmcr);
>> }
>>
>> -static int __armv8_pmuv3_map_event_id(struct arm_pmu *armpmu,
>> - struct perf_event *event)
>> -{
>> - if (event->attr.type == PERF_TYPE_HARDWARE &&
>> - event->attr.config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS) {
>> -
>> - if (test_bit(ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED,
>> - armpmu->pmceid_bitmap))
>> - return ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED;
>> -
>> - if (test_bit(ARMV8_PMUV3_PERFCTR_BR_RETIRED,
>> - armpmu->pmceid_bitmap))
>> - return ARMV8_PMUV3_PERFCTR_BR_RETIRED;
>
> If BR_RETIRED event is absent on the platform, PC_WRITE_RETIRED still remains
> a good alternative to fallback on. Hence wondering if the above order could
> just be changed to use BR_RETIRED first when available.
If PC_WRITE_RETIRED is a good alternative, then I guess, it's just better
change the order of those two. I send a new version just doing that.
Cheers, Ilkka
prev parent reply other threads:[~2024-09-06 18:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 20:47 Ilkka Koskinen
2024-09-06 4:58 ` Anshuman Khandual
2024-09-06 18:28 ` Ilkka Koskinen [this message]
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=ea7ff9b-b91c-d158-dfde-4569784a4720@os.amperecomputing.com \
--to=ilkka@os.amperecomputing.com \
--cc=anshuman.khandual@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--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
all inboxes | Powered by JetHome®