All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Aishwarya TCV <aishwarya.tcv@arm.com>, Ian Rogers <irogers@google.com>
Cc: Tuan Phan <tuanphan@os.amperecomputing.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Thomas Richter <tmricht@linux.ibm.com>,
	Bhaskara Budiredla <bbudiredla@marvell.com>,
	Bharat Bhushan <bbhushan2@marvell.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Ravi Bangoria <ravi.bangoria@amd.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	Will Deacon <will@kernel.org>,
	Stephane Eranian <eranian@google.com>,
	Mark Brown <broonie@kernel.org>,
	Naresh Kamboju <naresh.kamboju@linaro.org>
Subject: Re: [PATCH v6 1/2] perf pmus: Sort/merge/aggregate PMUs like mrvl_ddr_pmu
Date: Wed, 12 Jun 2024 13:28:08 +0100	[thread overview]
Message-ID: <8112b2bf-3950-4889-96bf-2317fbfb4bee@arm.com> (raw)
In-Reply-To: <ce31a50b-53db-4c6f-9cb1-242280b0951c@arm.com>



On 12/06/2024 12:19, Aishwarya TCV wrote:
> 
> 
> On 15/05/2024 07:01, Ian Rogers wrote:
>> The mrvl_ddr_pmu is uncore and has a hexadecimal address suffix while
>> the previous PMU sorting/merging code assumes uncore PMU names start
>> with uncore_ and have a decimal suffix. Because of the previous
>> assumption it isn't possible to wildcard the mrvl_ddr_pmu.
>>
>> Modify pmu_name_len_no_suffix but also remove the suffix number out
>> argument, this is because we don't know if a suffix number of say 100
>> is in hexadecimal or decimal. As the only use of the suffix number is
>> in comparisons, it is safe there to compare the values as hexadecimal.
>> Modify perf_pmu__match_ignoring_suffix so that hexadecimal suffixes
>> are ignored.
>>
>> Only allow hexadecimal suffixes to be greater than length 2 (ie 3 or
>> more) so that S390's cpum_cf PMU doesn't lose its suffix.
>>
>> Change the return type of pmu_name_len_no_suffix to size_t to
>> workaround GCC incorrectly determining the result could be negative.
>>
>> Signed-off-by: Ian Rogers <irogers@google.com>
>> ---
>>  tools/perf/util/pmu.c  | 33 +++++++++++++--------
>>  tools/perf/util/pmus.c | 67 ++++++++++++++++++++++++------------------
>>  tools/perf/util/pmus.h |  7 ++++-
>>  3 files changed, 65 insertions(+), 42 deletions(-)
>>
> 
> Hi Ian,
> 
> Perf test "perf_all_PMU_test" is failing when run against
> next-master(next-20240612) kernel with Arm64 on JUNO in our CI. It looks
> like it is failing when run on JUNO alone. Verified by running on other
> boards like RB5 and Ampere_altra and confirming that it does not fail on
> these boards. Suspecting that the suffixed 'armv8_pmuv3_0' naming could
> be the reason of test failure.
> 
> Reverting the change (3241d46f5f54) seems to fix it.
> 
> This works fine on Linux version v6.10-rc3
> 
> Failure log
> ------------
> 110: perf all PMU test:
> --- start ---
> test child forked, pid 8279
> Testing armv8_pmuv3/br_immed_retired/
> Event 'armv8_pmuv3/br_immed_retired/' not printed in:
> # Running 'internals/synthesize' benchmark:
> Computing performance of single threaded perf event synthesis by
> synthesizing events on the perf process itself:
>   Average synthesis took: 1169.431 usec (+- 0.144 usec)
>   Average num. events: 35.000 (+- 0.000)
>   Average time per event 33.412 usec
>   Average data synthesis took: 1225.698 usec (+- 0.102 usec)
>   Average num. events: 119.000 (+- 0.000)
>   Average time per event 10.300 usec
> 
>  Performance counter stats for 'perf bench internals synthesize':
> 
>         3263664785      armv8_pmuv3_0/br_immed_retired/
> 
> 
>       25.472854464 seconds time elapsed
> 
>        8.004791000 seconds user
>       17.060209000 seconds sys
> ---- end(-1) ----
> 110: perf all PMU test                                               :
> FAILED!
> 
> Thanks,
> Aishwarya
> 

I can take this one, the test can probably be relaxed to not care about
the suffix. Or maybe change what we print in the stat output to match
the string that the event was opened with.

Not sure which way is best yet but it will probably become more obvious
after some digging.

James


  reply	other threads:[~2024-06-12 12:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15  6:01 [PATCH v6 0/2] perf pmus: Sort/merge/aggregate PMUs like mrvl_ddr_pmu Ian Rogers
2024-05-15  6:01 ` [PATCH v6 1/2] " Ian Rogers
2024-06-12 11:19   ` Aishwarya TCV
2024-06-12 12:28     ` James Clark [this message]
2024-06-12 12:32     ` Ian Rogers
2024-06-12 13:12       ` James Clark
2024-06-12 13:56       ` Robin Murphy
2024-06-12 14:56         ` Ian Rogers
2024-05-15  6:01 ` [PATCH v6 2/2] perf tests: Add some pmu core functionality tests Ian Rogers
2024-05-23  3:54 ` [PATCH v6 0/2] perf pmus: Sort/merge/aggregate PMUs like mrvl_ddr_pmu Namhyung Kim
2024-05-29 19:24 ` Namhyung Kim

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=8112b2bf-3950-4889-96bf-2317fbfb4bee@arm.com \
    --to=james.clark@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=aishwarya.tcv@arm.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bbhushan2@marvell.com \
    --cc=bbudiredla@marvell.com \
    --cc=broonie@kernel.org \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=robin.murphy@arm.com \
    --cc=tmricht@linux.ibm.com \
    --cc=tuanphan@os.amperecomputing.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.