Message ID | 20220604042820.2270916-1-leo.yan@linaro.org (mailing list archive) |
---|---|
Headers | show |
Series | perf c2c: Support data source and display for Arm64 | expand |
Em Sat, Jun 04, 2022 at 12:28:03PM +0800, Leo Yan escreveu: > Arm64 Neoverse CPUs supports data source in Arm SPE trace, this allows > us to detect cache line contention and transfers. > > This patch set includes Ali's patch set v9 "perf: arm-spe: Decode SPE > source and use for perf c2c" [1] and rebased on the latest perf core > banch with latest commit 1bcca2b1bd67 ("perf vendor events intel: > Update metrics for Alderlake"). > > Patches 01-05 comes from Ali's patch set to support data source for Arm > SPE for neoverse cores. Leo, please remove touching the kernel perf_event.h on the first patch, I see it doesn't affect the kernel right now as it is done just from synthesizing perf records from hw trace data, and we haven't received any review comment from Peter Zijlstra (I think he is in vacations). Also please refresh it: ⬢[acme@toolbox perf]$ git am ./v5_20220604_leo_yan_perf_c2c_support_data_source_and_display_for_arm64.mbx Applying: perf: Add SNOOP_PEER flag to perf mem data struct Applying: perf tools: sync addition of PERF_MEM_SNOOPX_PEER Applying: perf mem: Print snoop peer flag Applying: perf arm-spe: Don't set data source if it's not a memory operation error: patch failed: tools/perf/util/arm-spe.c:387 error: tools/perf/util/arm-spe.c: patch does not apply Patch failed at 0004 perf arm-spe: Don't set data source if it's not a memory operation hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ⬢[acme@toolbox perf]$ - Arnaldo > Patches 06-17 are patches from patch set v4 for support perf c2c peer > display for Arm64 [2]. > > This patch set has been verified for both x86 perf memory events and Arm > SPE events. > > [1] https://lore.kernel.org/lkml/20220517020326.18580-1-alisaidi@amazon.com/ > [2] https://lore.kernel.org/lkml/20220530114036.3225544-1-leo.yan@linaro.org/ > > Changes from v4: > * Included Ali's patch set for adding data source in Arm SPE samples; > * Added Ian's ACK and Ali's review and test tags; > * Update document for the default peer dispaly for Arm64 (Ali). > > Changes from v3: > * Changed to display remote and local peer accesses (Joe); > * Fixed the usage info for display types (Joe); > * Do not display HITM dimensions when use 'peer' display, and HITM > display doesn't show any 'peer' dimensions (James); > * Split to smaller patches for adding dimensions of peer operations; > * Updated documentation to reflect the latest GUI and stdio. > > Changes from v2: > * Updated patch 04 to account metrics for both cache level and ld_peer > for PEER flag; > * Updated document for metric 'rmt_hit' which is accounted for all > remote accesses (include remote DRAM and any upward caches). > > Changes from v1: > * Updated patches 01, 02 and 03 to support 'N/A' metrics for store > operations, so can align with the patch set [1] for store samples. > > > Ali Saidi (3): > perf: Add SNOOP_PEER flag to perf mem data struct > perf tools: sync addition of PERF_MEM_SNOOPX_PEER > perf arm-spe: Use SPE data source for neoverse cores > > Leo Yan (14): > perf mem: Print snoop peer flag > perf arm-spe: Don't set data source if it's not a memory operation > perf mem: Add statistics for peer snooping > perf c2c: Output statistics for peer snooping > perf c2c: Add dimensions for peer load operations > perf c2c: Add dimensions of peer metrics for cache line view > perf c2c: Add mean dimensions for peer operations > perf c2c: Use explicit names for display macros > perf c2c: Rename dimension from 'percent_hitm' to > 'percent_costly_snoop' > perf c2c: Refactor node header > perf c2c: Refactor display string > perf c2c: Sort on peer snooping for load operations > perf c2c: Use 'peer' as default display for Arm64 > perf c2c: Update documentation for new display option 'peer' > > include/uapi/linux/perf_event.h | 2 +- > tools/include/uapi/linux/perf_event.h | 2 +- > tools/perf/Documentation/perf-c2c.txt | 31 +- > tools/perf/builtin-c2c.c | 454 ++++++++++++++---- > .../util/arm-spe-decoder/arm-spe-decoder.c | 1 + > .../util/arm-spe-decoder/arm-spe-decoder.h | 12 + > tools/perf/util/arm-spe.c | 140 +++++- > tools/perf/util/mem-events.c | 46 +- > tools/perf/util/mem-events.h | 3 + > 9 files changed, 550 insertions(+), 141 deletions(-) > > -- > 2.25.1
Hi Arnaldo, On Wed, Aug 10, 2022 at 10:37:32AM -0300, Arnaldo Carvalho de Melo wrote: > Em Sat, Jun 04, 2022 at 12:28:03PM +0800, Leo Yan escreveu: > > Arm64 Neoverse CPUs supports data source in Arm SPE trace, this allows > > us to detect cache line contention and transfers. > > > > This patch set includes Ali's patch set v9 "perf: arm-spe: Decode SPE > > source and use for perf c2c" [1] and rebased on the latest perf core > > banch with latest commit 1bcca2b1bd67 ("perf vendor events intel: > > Update metrics for Alderlake"). > > > > Patches 01-05 comes from Ali's patch set to support data source for Arm > > SPE for neoverse cores. > > Leo, please remove touching the kernel perf_event.h on the first patch, > I see it doesn't affect the kernel right now as it is done just from > synthesizing perf records from hw trace data, and we haven't received > any review comment from Peter Zijlstra (I think he is in vacations). Done! The new patch set іs in below link, which dropped the patch for kernel perf_event.h: https://lore.kernel.org/lkml/20220811062451.435810-1-leo.yan@linaro.org/ One question: should I later continue to upstream the first patch for syncing the kernel header perf_event.h after Peter.Z comes back? > Also please refresh it: > > ⬢[acme@toolbox perf]$ git am ./v5_20220604_leo_yan_perf_c2c_support_data_source_and_display_for_arm64.mbx > Applying: perf: Add SNOOP_PEER flag to perf mem data struct > Applying: perf tools: sync addition of PERF_MEM_SNOOPX_PEER > Applying: perf mem: Print snoop peer flag > Applying: perf arm-spe: Don't set data source if it's not a memory operation > error: patch failed: tools/perf/util/arm-spe.c:387 > error: tools/perf/util/arm-spe.c: patch does not apply > Patch failed at 0004 perf arm-spe: Don't set data source if it's not a memory operation > hint: Use 'git am --show-current-patch=diff' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > ⬢[acme@toolbox perf]$ To fix the merging conflict in the new patch set, I also dropped the patch "perf arm-spe: Don't set data source if it's not a memory operation", since this patch has been merged into the mainline kernel. Note, when verified the patch set, I found a compilation error, so I sent a separate patch to fix it: https://lore.kernel.org/lkml/20220811044341.426796-1-leo.yan@linaro.org/ Thanks a lot for continuous tracking this series. Leo
Em Thu, Aug 11, 2022 at 02:41:22PM +0800, Leo Yan escreveu: > Hi Arnaldo, > > On Wed, Aug 10, 2022 at 10:37:32AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Sat, Jun 04, 2022 at 12:28:03PM +0800, Leo Yan escreveu: > > > Arm64 Neoverse CPUs supports data source in Arm SPE trace, this allows > > > us to detect cache line contention and transfers. > > > > > > This patch set includes Ali's patch set v9 "perf: arm-spe: Decode SPE > > > source and use for perf c2c" [1] and rebased on the latest perf core > > > banch with latest commit 1bcca2b1bd67 ("perf vendor events intel: > > > Update metrics for Alderlake"). > > > > > > Patches 01-05 comes from Ali's patch set to support data source for Arm > > > SPE for neoverse cores. > > > > Leo, please remove touching the kernel perf_event.h on the first patch, > > I see it doesn't affect the kernel right now as it is done just from > > synthesizing perf records from hw trace data, and we haven't received > > any review comment from Peter Zijlstra (I think he is in vacations). > > Done! The new patch set іs in below link, which dropped the patch for > kernel perf_event.h: > https://lore.kernel.org/lkml/20220811062451.435810-1-leo.yan@linaro.org/ > > One question: should I later continue to upstream the first patch for > syncing the kernel header perf_event.h after Peter.Z comes back? yes, and we may have to backtrack and find some other way to implement this if he is opposed, as he in the past didn't like perf_event_attr.type namespace being used by userspace only records such as PERF_RECORD_FINISHED_ROUND, PERF_RECORD_COMPRESSED, etc. In this case its different, I think its ok as we already have PERF_MEM_SNOOPX_FWD and PERF_MEM_SNOOPX_PEER probably will be emitted by the some of the architectures, from the kernel, right? - Arnaldo > > Also please refresh it: > > > > ⬢[acme@toolbox perf]$ git am ./v5_20220604_leo_yan_perf_c2c_support_data_source_and_display_for_arm64.mbx > > Applying: perf: Add SNOOP_PEER flag to perf mem data struct > > Applying: perf tools: sync addition of PERF_MEM_SNOOPX_PEER > > Applying: perf mem: Print snoop peer flag > > Applying: perf arm-spe: Don't set data source if it's not a memory operation > > error: patch failed: tools/perf/util/arm-spe.c:387 > > error: tools/perf/util/arm-spe.c: patch does not apply > > Patch failed at 0004 perf arm-spe: Don't set data source if it's not a memory operation > > hint: Use 'git am --show-current-patch=diff' to see the failed patch > > When you have resolved this problem, run "git am --continue". > > If you prefer to skip this patch, run "git am --skip" instead. > > To restore the original branch and stop patching, run "git am --abort". > > ⬢[acme@toolbox perf]$ > > To fix the merging conflict in the new patch set, I also dropped the > patch "perf arm-spe: Don't set data source if it's not a memory > operation", since this patch has been merged into the mainline kernel. Thanks. > Note, when verified the patch set, I found a compilation error, so I > sent a separate patch to fix it: > https://lore.kernel.org/lkml/20220811044341.426796-1-leo.yan@linaro.org/ I think we have a good enough bandaid in place, with that arm-spe.o only additional -I it builds on all build containers I have, the ones failing are for unrelated reasons: [perfbuilder@five ~]$ export BUILD_TARBALL=http://192.168.86.14/perf/perf-5.19.0.tar.xz [perfbuilder@five ~]$ time dm 1 131.61 almalinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4) , clang version 12.0.1 (Red Hat 12.0.1-4.module_el8.5.0+1025+93159d6c) 2 124.99 almalinux:9 : Ok gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) , clang version 13.0.1 (Red Hat 13.0.1-1.el9) 3 29.18 alpine:3.9 : Ok gcc (Alpine 8.3.0) 8.3.0 , clang version 13.0.1 (Red Hat 13.0.1-1.el9) 4 124.11 alpine:3.10 : Ok gcc (Alpine 8.3.0) 8.3.0 , Alpine clang version 8.0.0 (tags/RELEASE_800/final) (based on LLVM 8.0.0) 5 133.59 alpine:3.11 : Ok gcc (Alpine 9.3.0) 9.3.0 , Alpine clang version 9.0.0 (https://git.alpinelinux.org/aports f7f0d2c2b8bcd6a5843401a9a702029556492689) (based on LLVM 9.0.0) 6 128.81 alpine:3.12 : Ok gcc (Alpine 9.3.0) 9.3.0 , Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git 7445adce501f8473efdb93b17b5eaf2f1445ed4c) 7 134.70 alpine:3.13 : Ok gcc (Alpine 10.2.1_pre1) 10.2.1 20201203 , Alpine clang version 10.0.1 8 135.21 alpine:3.14 : Ok gcc (Alpine 10.3.1_git20210424) 10.3.1 20210424 , Alpine clang version 11.1.0 9 137.62 alpine:3.15 : Ok gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027 , Alpine clang version 12.0.1 10 127.40 alpine:3.16 : Ok gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219 , Alpine clang version 13.0.1 11 129.80 alpine:edge : Ok gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219 , Alpine clang version 14.0.6 12 25.85 alt:p8 : Ok x86_64-alt-linux-gcc (GCC) 5.3.1 20151207 (ALT p8 5.3.1-alt3.M80P.1) , Alpine clang version 14.0.6 13 83.87 alt:p9 : Ok x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1) , clang version 10.0.0 14 95.90 alt:p10 : Ok x86_64-alt-linux-gcc (GCC) 10.3.1 20210703 (ALT Sisyphus 10.3.1-alt2) , clang version 11.0.1 15 96.50 alt:sisyphus : FAIL gcc version 12.1.1 20220518 (ALT Sisyphus 12.1.1-alt1) (GCC) /usr/lib/llvm-13.0/include/clang/AST/DeclBase.h: In instantiation of 'void clang::DeclContext::filtered_decl_iterator<SpecificDecl, Acceptable>::SkipToNextDecl() [with SpecificDecl = clang::ObjCPropertyDecl; bool (SpecificDecl::* Acceptable)() const = &clang::ObjCPropertyDecl::isInstanceProperty]': 16 108.04 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15) , clang version 11.1.0 (Amazon Linux 2 11.1.0-1.amzn2.0.2) 17 130.10 amazonlinux:devel : Ok gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2) , clang version 12.0.1 (Fedora 12.0.1-1.amzn2022) 18 138.10 archlinux:base : Ok gcc (GCC) 12.1.1 20220730 , clang version 14.0.6 19 107.93 centos:8 : Ok gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) , clang version 11.0.1 (Red Hat 11.0.1-1.module_el8.4.0+966+2995ef20) 20 117.97 centos:stream : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-15) , clang version 14.0.0 (Red Hat 14.0.0-1.module_el8.7.0+1142+5343df54) 21 35.30 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 12.1.1 20220803 releases/gcc-12.1.0-322-g3df2f03587 , clang version 14.0.0 (Red Hat 14.0.0-1.module_el8.7.0+1142+5343df54) 22 22.85 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 , clang version 14.0.0 (Red Hat 14.0.0-1.module_el8.7.0+1142+5343df54) 23 89.39 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0 , Debian clang version 11.0.1-2~deb10u1 24 107.93 debian:11 : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2 25 129.52 debian:experimental : Ok gcc (Debian 12.1.0-7) 12.1.0 , Debian clang version 14.0.6-2 26 26.47 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 11.3.0-3) 11.3.0 27 22.25 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 11.2.0-18) 11.2.0 28 23.86 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 10.2.1-6) 10.2.1 20210110 29 24.56 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 11.2.0-18) 11.2.0 30 24.75 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) 31 26.36 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) 32 19.74 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710 33 26.27 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1) 34 27.17 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) 35 27.67 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6) 36 111.72 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 6.0.1 (tags/RELEASE_601/final) 37 117.14 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) , clang version 7.0.1 (Fedora 7.0.1-6.fc29) 38 121.34 fedora:30 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 8.0.0 (Fedora 8.0.0-3.fc30) 39 121.06 fedora:31 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) , clang version 9.0.1 (Fedora 9.0.1-4.fc31) 40 103.71 fedora:32 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 10.0.1 (Fedora 10.0.1-3.fc32) 41 124.68 fedora:33 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 11.0.0 (Fedora 11.0.0-3.fc33) 42 134.50 fedora:34 : Ok gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2) , clang version 12.0.1 (Fedora 12.0.1-1.fc34) 43 21.65 fedora:34-x-ARC-glibc : Ok arc-linux-gcc (ARC HS GNU/Linux glibc toolchain 2019.03-rc1) 8.3.1 20190225 44 19.84 fedora:34-x-ARC-uClibc : Ok arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 45 139.75 fedora:35 : Ok gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2) , clang version 13.0.0 (Fedora 13.0.0-3.fc35) 46 140.06 fedora:36 : Ok gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1) , clang version 14.0.0 (Fedora 14.0.0-1.fc36) 47 140.95 fedora:37 : Ok gcc (GCC) 12.1.1 20220628 (Red Hat 12.1.1-3) , clang version 14.0.5 (Fedora 14.0.5-5.fc37) 48 140.23 fedora:rawhide : Ok gcc (GCC) 12.1.1 20220628 (Red Hat 12.1.1-3) , clang version 14.0.5 (Fedora 14.0.5-5.fc37) 49 116.96 gentoo-stage3:latest : Ok gcc (Gentoo 11.2.0 p1) 11.2.0 , clang version 13.0.0 50 30.88 mageia:7 : Ok gcc (Mageia 8.4.0-1.mga7) 8.4.0 , clang version 13.0.0 51 10.61 mageia:8 : FAIL gcc version 10.4.0 (Mageia 10.4.0-3.mga8) ImportError: No module named setuptools cp: cannot stat '/tmp/build/perf/python_ext_build/lib/perf*.so': No such file or directory 52 131.50 manjaro:base : Ok gcc (GCC) 11.1.0 , clang version 13.0.0 53 7.18 openmandriva:4.2 : FAIL gcc version 11.2.0 20210728 (OpenMandriva) (GCC) In file included from builtin-bench.c:22: bench/bench.h:68:19: error: conflicting types for 'pthread_attr_setaffinity_np'; have 'int(pthread_attr_t *, size_t, cpu_set_t *)' {aka 'int(pthread_attr_t *, long unsigned int, cpu_set_t *)'} 68 | static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr __maybe_unused, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 54 7.08 openmandriva:cooker : FAIL gcc version 11.2.0 20210728 (OpenMandriva) (GCC) In file included from builtin-bench.c:22: bench/bench.h:68:19: error: conflicting types for 'pthread_attr_setaffinity_np'; have 'int(pthread_attr_t *, size_t, cpu_set_t *)' {aka 'int(pthread_attr_t *, long unsigned int, cpu_set_t *)'} 68 | static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr __maybe_unused, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 55 41.21 opensuse:15.0 : Ok gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407] , OpenMandriva 13.0.0-1 clang version 13.0.0 (/builddir/build/BUILD/llvm-project-13.0.0.src/clang 69c9d9094dd9c820a6ba8cad88f5901643d8f257) 56 137.78 opensuse:15.1 : Ok gcc (SUSE Linux) 7.5.0 , clang version 7.0.1 (tags/RELEASE_701/final 349238) 57 131.97 opensuse:15.2 : Ok gcc (SUSE Linux) 7.5.0 , clang version 9.0.1 58 150.03 opensuse:15.3 : Ok gcc (SUSE Linux) 7.5.0 , clang version 11.0.1 59 152.63 opensuse:15.4 : Ok gcc (SUSE Linux) 7.5.0 , clang version 13.0.1 60 181.35 opensuse:tumbleweed : Ok gcc (SUSE Linux) 12.1.1 20220629 [revision 7811663964aa7e31c3939b859bbfa2e16919639f] , clang version 14.0.6 61 124.89 oraclelinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4.0.1) , clang version 12.0.1 (Red Hat 12.0.1-4.0.1.module+el8.5.0+20428+2b4ecd47) 62 118.96 oraclelinux:9 : Ok gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9.4.0.2) , clang version 13.0.1 (Red Hat 13.0.1-1.0.1.el9) 63 116.66 rockylinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10) , clang version 13.0.1 (Red Hat 13.0.1-2.module+el8.6.0+987+d36ea6a1) 64 121.77 rockylinux:9 : Ok gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) , clang version 13.0.1 (Red Hat 13.0.1-1.el9) 65 24.75 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609 , clang version 13.0.1 (Red Hat 13.0.1-1.el9) 66 20.94 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 67 20.75 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 68 20.95 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 69 20.85 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 70 98.89 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 , clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) 71 22.45 ubuntu:18.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 72 22.55 ubuntu:18.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 73 18.33 ubuntu:18.04-x-m68k : Ok m68k-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 74 21.75 ubuntu:18.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 75 23.36 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 76 23.36 ubuntu:18.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 77 110.06 ubuntu:18.04-x-riscv64 : Ok riscv64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 78 20.55 ubuntu:18.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 79 21.56 ubuntu:18.04-x-sh4 : Ok sh4-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 80 20.14 ubuntu:18.04-x-sparc64 : Ok sparc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 81 30.08 ubuntu:20.04 : Ok gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 82 24.37 ubuntu:20.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 83 121.26 ubuntu:21.04 : Ok gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 , Ubuntu clang version 12.0.0-3ubuntu1~21.04.2 84 123.37 ubuntu:21.10 : Ok gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0 , Ubuntu clang version 13.0.0-2 85 141.34 ubuntu:22.04 : Ok gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 , Ubuntu clang version 14.0.0-1ubuntu1 86 131.33 ubuntu:22.10 : Ok gcc (Ubuntu 11.3.0-5ubuntu1) 11.3.0 , Ubuntu clang version 14.0.6-2 BUILD_TARBALL_HEAD=e754dd7e8be86e1adc9d4d13fb1105b848c11752 87 6976.47 real 117m55.077s user 1m18.659s sys 0m53.139s [perfbuilder@five ~]$ > Thanks a lot for continuous tracking this series. You're welcome. - Arnaldo
On Fri, Aug 12, 2022 at 09:43:07AM -0300, Arnaldo Carvalho de Melo wrote: [...] > > One question: should I later continue to upstream the first patch for > > syncing the kernel header perf_event.h after Peter.Z comes back? > > yes, and we may have to backtrack and find some other way to implement > this if he is opposed, as he in the past didn't like > perf_event_attr.type namespace being used by userspace only records such > as PERF_RECORD_FINISHED_ROUND, PERF_RECORD_COMPRESSED, etc. > > In this case its different, I think its ok as we already have > PERF_MEM_SNOOPX_FWD and PERF_MEM_SNOOPX_PEER probably will be emitted by > the some of the architectures, from the kernel, right? Yes, as I know x86 generates memory samples from kernel, and SNOOPX_PEER can be a useful snooping flag for other archs. As a last resort if SNOOPX_PEER is rejected, we can rollback to use existed flag (like reusing PERF_MEM_SNOOPX_FWD), though this would be ambiguous for expressing the memory operations on Arm64. Thanks, Leo