From: James Clark <james.clark@arm.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
Jing Zhang <renyu.zj@linux.alibaba.com>
Cc: Haixin Yu <yuhaixin.yhx@linux.alibaba.com>,
John Garry <john.g.garry@oracle.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Leo Yan <leo.yan@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf arm64: Fix read PMU cpu slots
Date: Tue, 25 Jul 2023 11:15:29 +0100 [thread overview]
Message-ID: <56e70195-5f58-ca03-d6fd-f73e91f56298@arm.com> (raw)
In-Reply-To: <ZL6pxZ4RmMC2W7S+@kernel.org>
On 24/07/2023 17:41, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jul 24, 2023 at 03:40:12PM +0800, Jing Zhang escreveu:
>>
>>
>> 在 2023/7/24 下午1:06, Haixin Yu 写道:
>>> Commit f8ad6018ce3c ("perf pmu: Remove duplication around
>>> EVENT_SOURCE_DEVICE_PATH") uses sysfs__read_ull to read a full
>>> sysfs path, which will never success. Fix it by read file directly.
>>>
>>> Signed-off-by: Haixin Yu <yuhaixin.yhx@linux.alibaba.com>
>>> ---
>>> tools/perf/arch/arm64/util/pmu.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
>>> index 561de0cb6b95..512a8f13c4de 100644
>>> --- a/tools/perf/arch/arm64/util/pmu.c
>>> +++ b/tools/perf/arch/arm64/util/pmu.c
>>> @@ -54,10 +54,11 @@ double perf_pmu__cpu_slots_per_cycle(void)
>>> perf_pmu__pathname_scnprintf(path, sizeof(path),
>>> pmu->name, "caps/slots");
>>> /*
>>> - * The value of slots is not greater than 32 bits, but sysfs__read_int
>>> - * can't read value with 0x prefix, so use sysfs__read_ull instead.
>>> + * The value of slots is not greater than 32 bits, but
>>> + * filename__read_int can't read value with 0x prefix,
>>> + * so use filename__read_ull instead.
>>> */
>>> - sysfs__read_ull(path, &slots);
>>> + filename__read_ull(path, &slots);
>>> }
>>>
>>> return slots ? (double)slots : NAN;
>>
>> Yes, the function perf_pmu__pathname_scnprintf returns the complete slots file path "/sys/bus/xxxxx/caps/slots",
>> and sysfs__read_ull will add the prefix "/sys" to the path, so the final file path becomes "/sys/sys/bus/xxxx/caps/slots"
>> which does not exist, and the slots file cannot be successfully read, so sysfs__read_ull needs to be changed to the
>> filename__read_ull.
>>
>> I tested it and it works well.
>>
>> Tested-by: Jing Zhang <renyu.zj@linux.alibaba.com>
>
> I've applied this to my local branch, thanks.
>
> I also added the missing:
>
> Fixes: f8ad6018ce3c065a ("perf pmu: Remove duplication around EVENT_SOURCE_DEVICE_PATH")
>
> This is another case where a 'perf test' entry would come in handy.
>
> James, please check and ack,
>
> - Arnaldo
Oops, looks like the system I tested that on doesn't report slots so it
returns NAN whether it successfully reads the file or not.
I can't think of a test that doesn't just repeat that function so I will
probably say to leave it as is (and we're not currently doing any
automated testing on any platforms that report slots either). It's quite
visible when it breaks because the topdown metrics won't work on
platforms where they should.
Sorry for the breakage!
Acked-by: James Clark <james.clark@arm.com>
prev parent reply other threads:[~2023-07-25 10:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 5:06 Haixin Yu
2023-07-24 7:40 ` Jing Zhang
2023-07-24 16:41 ` Arnaldo Carvalho de Melo
2023-07-25 10:15 ` James Clark [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=56e70195-5f58-ca03-d6fd-f73e91f56298@arm.com \
--to=james.clark@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@linaro.org \
--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=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=renyu.zj@linux.alibaba.com \
--cc=will@kernel.org \
--cc=yuhaixin.yhx@linux.alibaba.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 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®