Re: [PATCH v6 00/15] perf c2c: Support data source and display for Arm64
From: Leo Yan
Date: Thu Aug 11 2022 - 21:27:06 EST
Hi Arnaldo,
On Thu, Aug 11, 2022 at 07:25:35PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 11, 2022 at 02:24:36PM +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 has been rebased on the acme/perf/core branch with the latest
> > commit b39c9e1b101d ("perf machine: Fix missing free of
> > machine->kallsyms_filename").
> >
> > To make building success, a compilation fixing commit [1] has been sent
> > to LKML, this patch set is dependent on it. This patch set has been verified
> > for both x86 perf memory events and Arm SPE events.
> >
> > [1] https://lore.kernel.org/lkml/20220811044341.426796-1-leo.yan@xxxxxxxxxx/
>
> So, I tentatively applied this set after applying the patch for
> <asm/sysreg.h>, and its all now out in tmp.perf/core in my git tree,
> please check.
With discussing with Suzuki, he pointed it is not perfect for adding asm
include path in that way. With the patch on tmp.perf/core branch, two
include paths are added into CFLAGS for arm-spe.c:
-I$(srctree)/tools/arch/$(SRCARCH)/include/
-I$(srctree)/tools/arch/arm64/include/
When we build perf on x86_64, then $(srctree)/tools/arch/x86/include/
takes more precedence than $(srctree)/tools/arch/arm64/include/; if we
want to include header file without relative path in c code, like
"#include <asm/cputype.h>", then it has chance to find the same name
file from x86's asm folder rather than arm64's asm folder.
At yesterday, I spent couple hours to find other methods (like
filter-out, CFLAGS_REMOVE, etc) in makefile but it's no lucky to make
success to give precedence for $(srctree)/tools/arch/arm64/include/.
So current patches on the branch tmp.perf/core can build successfully,
but if have any better method to resolve the header path precedence
issue, then I prefer to improve for this, which can allow us later
don't worry about it. Any suggestion for this?
> I'm doing the usual set of container build tests, but any additional
> checking, including on the committer note I added to the first patch in
> this series, claryfing it is not really a "sync" with the kernel
> headers, is more than welcome.
It's fine for me for adding my Signed-off for the signature chain.
Appreicate for the amending.
Thanks,
Leo