From: James Clark <james.clark@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org,
Rob Herring <robh@kernel.org>,
raphael.gault@arm.com
Cc: Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: perf: arm_pmuv3: Update 'pmc_width' based on actual HW event width
Date: Tue, 10 Oct 2023 09:30:45 +0100 [thread overview]
Message-ID: <72d358f1-bcee-ee6d-48ca-a38b47aadf29@arm.com> (raw)
In-Reply-To: <948c6cdd-5a46-6b4b-37a9-9f971a4853a8@arm.com>
On 10/10/2023 09:28, James Clark wrote:
>
>
> On 10/10/2023 04:03, Anshuman Khandual wrote:
>> Hi James,
>>
>> On 10/9/23 15:13, James Clark wrote:
>>>
>>>
>>> On 09/10/2023 05:37, Anshuman Khandual wrote:
>>>> This updates 'perf_event_mmap_page->pmc_width' based on actual HW event's
>>>> width that are currently missing i.e ARMPMU_EVT_63BIT and ARMPMU_EVT_47BIT.
>>>>
>>>
>>> Might be worth adding why this is needed or what the actual effect is.
>>
>> To have correct 'pmc_width' visible to the user space ?
>
> Well yeah, but for example I didn't know what that was. And it's not
> clear why it needs updating at this point in time without a link to any
> other commit or relevant section from the Arm ARM. So I had a kind of a
> "why now" question.
>
> "To have correct 'pmc_width' visible to the user space" is definitely
> more of a what than a why.
>
If anything this should at least have a fixes: tag on it. If you're
saying that it's now correct.
>>
>>>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>>> ---
>>>> This applies on v6.6-rc5.
>>>>
>>>> drivers/perf/arm_pmuv3.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
>>>> index fe4db1831662..94723d00548e 100644
>>>> --- a/drivers/perf/arm_pmuv3.c
>>>> +++ b/drivers/perf/arm_pmuv3.c
>>>> @@ -1375,6 +1375,10 @@ void arch_perf_update_userpage(struct perf_event *event,
>>>> if (userpg->cap_user_rdpmc) {
>>>> if (event->hw.flags & ARMPMU_EVT_64BIT)
>>>> userpg->pmc_width = 64;
>>>> + else if (event->hw.flags & ARMPMU_EVT_63BIT)
>>>> + userpg->pmc_width = 63;
>>>> + else if (event->hw.flags & ARMPMU_EVT_47BIT)
>>>> + userpg->pmc_width = 47;
>>>
>>> Although it doesn't explicitly say it, the bit of the docs about
>>> pmc_width in Documentation/arch/arm64/perf.rst loosely implies that this
>>> is always either 64 or 32. Now that this isn't the case it could mislead
>>> someone in userspace that they don't have to handle the now arbitrary
>>> bit widths rather than just whole bytes/ints.
>>
>> Are you suggesting that the user space would not handle pmc_width correctly
>> , once it deviates from a whole bytes/ints format ? In that case user space
>> handling might need some fixing.
>>
>
> Not really, I'm just suggesting that anyone writing a new tool and only
> reading the docs could make that assumption. Seeing as only 32 and 64
> bit options are mentioned. So it's more to avoid misleading someone in
> the future than about fixing any existing code, as updating the docs
> wouldn't have that effect.
>
>>>
>>> I think the fix is as simple as adding something like "the width may not
>>> match the requested value or necessarily be a multiple of 8". Unless we
>>> think this is already widely known and I suppose we could leave it as
>>> is. (The existing bit in perf that uses it already handles it correctly).
>>
>> This is from perf_event_mmap_page definition where it does not assert the
>> width to be multiple of bytes or ints. Hence the assumption should not be
>> made into the user space tools.
>>
>
> Yeah I know its already ok for Perf which is why I mentioned it. But
> there are more tools out there than Perf, and ones that don't even exist
> yet, which people would normally read the documentation before writing.
>
>> /*
>> * If cap_user_rdpmc this field provides the bit-width of the value
>> * read using the rdpmc() or equivalent instruction. This can be used
>> * to sign extend the result like:
>> *
>> * pmc <<= 64 - width;
>> * pmc >>= 64 - width; // signed shift right
>> * count += pmc;
>> */
>> __u16 pmc_width;
>>
>> Moreover, on x86 too 'userpg->pmc_width' gets assigned to different values
>> although multiple of 8.
>>
>> userpg->pmc_width = x86_pmu.cntval_bits
>> arch/x86/events/amd/core.c: .cntval_bits = 48
>> arch/x86/events/intel/knc.c: .cntval_bits = 40
>> arch/x86/events/intel/p6.c: .cntval_bits = 32
>>
>>>
>>>> else
>>>> userpg->pmc_width = 32;
>>>> }
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-10 8:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 4:37 [PATCH] drivers: perf: arm_pmuv3: Update 'pmc_width' based on actual HW event width Anshuman Khandual
2023-10-09 9:43 ` James Clark
2023-10-10 3:03 ` Anshuman Khandual
2023-10-10 8:28 ` James Clark
2023-10-10 8:30 ` James Clark [this message]
2023-10-10 11:38 ` Robin Murphy
2023-10-12 9:05 ` Mark Rutland
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=72d358f1-bcee-ee6d-48ca-a38b47aadf29@arm.com \
--to=james.clark@arm.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=raphael.gault@arm.com \
--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