From: Carsten Haitzler <carsten.haitzler(a)arm.com>
Perf test's shell runner will just run everything in the tests
directory (as long as it's not another directory or does not begin
with a dot), but sometimes you find files in there that are not shell
scripts - perf.data output for example if you do some testing and then
the next time you run perf test it tries to run these. Check the files
are executable so they are actually intended to be test scripts and
not just some "random junk" files there.
Signed-off-by: Carsten Haitzler <carsten.haitzler(a)arm.com>
---
tools/perf/tests/builtin-test.c | 4 +++-
tools/perf/util/path.c | 14 +++++++++++++-
tools/perf/util/path.h | 1 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index fac3717d9ba1..3c34cb766724 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -296,7 +296,9 @@ static const char *shell_test__description(char *description, size_t size,
#define for_each_shell_test(entlist, nr, base, ent) \
for (int __i = 0; __i < nr && (ent = entlist[__i]); __i++) \
- if (!is_directory(base, ent) && ent->d_name[0] != '.')
+ if (!is_directory(base, ent) && \
+ is_executable_file(base, ent) && \
+ ent->d_name[0] != '.')
static const char *shell_tests__dir(char *path, size_t size)
{
diff --git a/tools/perf/util/path.c b/tools/perf/util/path.c
index caed0336429f..ce80b79be103 100644
--- a/tools/perf/util/path.c
+++ b/tools/perf/util/path.c
@@ -86,9 +86,21 @@ bool is_directory(const char *base_path, const struct dirent *dent)
char path[PATH_MAX];
struct stat st;
- sprintf(path, "%s/%s", base_path, dent->d_name);
+ snprintf(path, sizeof(path), "%s/%s", base_path, dent->d_name);
if (stat(path, &st))
return false;
return S_ISDIR(st.st_mode);
}
+
+bool is_executable_file(const char *base_path, const struct dirent *dent)
+{
+ char path[PATH_MAX];
+ struct stat st;
+
+ snprintf(path, sizeof(path), "%s/%s", base_path, dent->d_name);
+ if (stat(path, &st))
+ return false;
+
+ return !S_ISDIR(st.st_mode) && (st.st_mode & S_IXUSR);
+}
diff --git a/tools/perf/util/path.h b/tools/perf/util/path.h
index 083429b7efa3..d94902c22222 100644
--- a/tools/perf/util/path.h
+++ b/tools/perf/util/path.h
@@ -12,5 +12,6 @@ int path__join3(char *bf, size_t size, const char *path1, const char *path2, con
bool is_regular_file(const char *file);
bool is_directory(const char *base_path, const struct dirent *dent);
+bool is_executable_file(const char *base_path, const struct dirent *dent);
#endif /* _PERF_PATH_H */
--
2.32.0
The current method for allocating trace source ID values to sources is
to use a fixed algorithm for CPU based sources of (cpu_num * 2 + 0x10).
The STM is allocated ID 0x1.
This fixed algorithm is used in both the CoreSight driver code, and by
perf when writing the trace metadata in the AUXTRACE_INFO record.
The method needs replacing as currently:-
1. It is inefficient in using available IDs.
2. Does not scale to larger systems with many cores and the algorithm
has no limits so will generate invalid trace IDs for cpu number > 44.
Additionally requirements to allocate additional system IDs on some
systems have been seen.
This patch set introduces an API that allows the allocation of trace IDs
in a dynamic manner.
Architecturally reserved IDs are never allocated, and the system is
limited to allocating only valid IDs.
Each of the current trace sources ETM3.x, ETM4.x and STM is updated to use
the new API.
perf handling is changed so that the ID associated with the CPU is read
from sysfs. The ID allocator is notified when perf events start and stop
so CPU based IDs are kept constant throughout any perf session.
For the ETMx.x devices IDs are allocated on certain events
a) When using sysfs, an ID will be allocated on hardware enable, and freed
when the sysfs reset is written.
b) When using perf, ID is allocated on hardware enable, and freed on
hardware disable.
For both cases the ID is allocated when sysfs is read to get the current
trace ID. This ensures that consistent decode metadata can be extracted
from the system where this read occurs before device enable.
Note: This patchset breaks backward compatibility for perf record.
Because the method for generating the AUXTRACE_INFO meta data has
changed, using an older perf record will result in metadata that
does not match the trace IDs used in the recorded trace data.
This mismatch will cause subsequent decode to fail. Older versions of
perf will still be able to decode data generated by the updated system.
Applies to coresight/next [b54f53bc11a5]
Tested on DB410c
Mike Leach (10):
coresight: trace-id: Add API to dynamically assign trace ID values
coresight: trace-id: Set up source trace ID map for system
coresight: stm: Update STM driver to use Trace ID api
coresight: etm4x: Use trace ID API to dynamically allocate trace ID
coresight: etm3x: Use trace ID API to allocate IDs
coresight: perf: traceid: Add perf notifiers for trace ID
perf: cs-etm: Update event to read trace ID from sysfs
coresight: Remove legacy Trace ID allocation mechanism
coresight: etmX.X: stm: Remove unused legacy source trace ID ops
coresight: trace-id: Add debug & test macros to trace id allocation
drivers/hwtracing/coresight/Makefile | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 64 ++---
.../hwtracing/coresight/coresight-etm-perf.c | 16 +-
drivers/hwtracing/coresight/coresight-etm.h | 3 +-
.../coresight/coresight-etm3x-core.c | 93 ++++---
.../coresight/coresight-etm3x-sysfs.c | 28 +-
.../coresight/coresight-etm4x-core.c | 63 ++++-
.../coresight/coresight-etm4x-sysfs.c | 32 ++-
drivers/hwtracing/coresight/coresight-etm4x.h | 3 +
drivers/hwtracing/coresight/coresight-priv.h | 1 +
drivers/hwtracing/coresight/coresight-stm.c | 49 +---
.../hwtracing/coresight/coresight-trace-id.c | 255 ++++++++++++++++++
.../hwtracing/coresight/coresight-trace-id.h | 69 +++++
include/linux/coresight-pmu.h | 12 -
include/linux/coresight.h | 3 -
tools/perf/arch/arm/util/cs-etm.c | 12 +-
16 files changed, 530 insertions(+), 175 deletions(-)
create mode 100644 drivers/hwtracing/coresight/coresight-trace-id.c
create mode 100644 drivers/hwtracing/coresight/coresight-trace-id.h
--
2.17.1
Hi Jinlong
On 09/03/2022 14:22, Mao Jinlong wrote:
> It is possibe that probe failure issue happens when the device
> and its child_device's probe happens at the same time.
> In coresight_make_links, has_conns_grp is true for parent, but
> has_conns_grp is false for child device as has_conns_grp is set
> to true in coresight_create_conns_sysfs_group. The probe of parent
> device will fail at this condition. Add has_conns_grp check for
> child device before make the links and make the process from
> device_register to connection_create be atomic to avoid this
> probe failure issue.
>
> Suggested-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Suggested-by: Mike Leach <mike.leach(a)linaro.org>
> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
Thanks for the rework. The patch looks good to me.
Suzuki
This allows enabling branch broadcast for Perf hosted sessions (the option
is currently only available for the sysfs interface). Hopefully this could
be useful for testing the decode in perf, for example does a determinisitic
run with branch broadcast enabled look the same as with it disabled? It
could also be used for scenarios like OpenJ9's support for JIT code:
java -Xjit:perfTool hello.java
Currently this is not working and you get the usual errors of a missing
DSO, but branch broadcast would have to be enabled anyway before working
through this next issue:
CS ETM Trace: Debug data not found for address 0xffff7b94b058 in /tmp/perf-29360.map
Address range support in Perf for branch broadcast has also not been added
here, but could be added later.
The documentation has been refactored slightly to allow updates to be made
that link the Perf format arguments with the existing documentation.
For Suzuki's comment, I will do it as a separate change that converts all
the other hard coded values to a more consistent sysreg.h style:
nit: While at this, please could you change the hard coded value
to ETM4_CFG_BIT_RETSTK ?
Changes since v1:
* Added Leo's reviewed by on patch 3
* Fix bracket styling
* Add documentation
Applies on top of coresight/next efa56eddf5d5c. But this docs fix is also
required to get the links to work:
https://marc.info/?l=linux-doc&m=164139331923986&w=2
Also available at: https://gitlab.arm.com/linux-arm/linux-jc/-/tree/james-branch-broadcast-v2
James Clark (6):
coresight: Add config flag to enable branch broadcast
coresight: Fail to open with return stacks if they are unavailable
perf cs-etm: Update deduction of TRCCONFIGR register for branch
broadcast
Documentation: coresight: Turn numbered subsections into real
subsections
Documentation: coresight: Link config options to existing
documentation
Documentation: coresight: Expand branch broadcast documentation
.../coresight/coresight-etm4x-reference.rst | 14 ++++-
Documentation/trace/coresight/coresight.rst | 56 +++++++++++++++++--
.../hwtracing/coresight/coresight-etm-perf.c | 2 +
.../coresight/coresight-etm4x-core.c | 23 ++++++--
include/linux/coresight-pmu.h | 2 +
tools/include/linux/coresight-pmu.h | 2 +
tools/perf/arch/arm/util/cs-etm.c | 3 +
7 files changed, 92 insertions(+), 10 deletions(-)
--
2.28.0
Changes since v2:
* Implement Mike's suggestion of not having _SHIFT and using the existing
FIELD_GET and FIELD_PREP methods.
* Dropped the change to add the new REG_VAL macro because of the above.
* FIELD_PREP could be used in some trivial cases, but in some cases the
shift is still required but can be calculated with __bf_shf
* Improved the commit messages.
* The change is still binary equivalent, but requires an extra step
mentioned at the end of this cover letter.
Applies to coresight/next 3619ee28488
Also available at https://gitlab.arm.com/linux-arm/linux-jc/-/tree/james-cs-register-refactor…
To check for binary equivalence follow the same steps in the cover letter
of v2, but apply the following change to coresight-priv.h. This is because
the existing version of the macros wrap the expression in a new scope {}
that flips something in the compiler:
#undef FIELD_GET
#define FIELD_GET(_mask, _reg) (((_reg) & (_mask)) >> __bf_shf(_mask))
#undef FIELD_PREP
#define FIELD_PREP(_mask, _val) (((_val) << __bf_shf(_mask)) & (_mask))
Thanks
James
James Clark (15):
coresight: etm4x: Cleanup TRCIDR0 register accesses
coresight: etm4x: Cleanup TRCIDR2 register accesses
coresight: etm4x: Cleanup TRCIDR3 register accesses
coresight: etm4x: Cleanup TRCIDR4 register accesses
coresight: etm4x: Cleanup TRCIDR5 register accesses
coresight: etm4x: Cleanup TRCCONFIGR register accesses
coresight: etm4x: Cleanup TRCEVENTCTL1R register accesses
coresight: etm4x: Cleanup TRCSTALLCTLR register accesses
coresight: etm4x: Cleanup TRCVICTLR register accesses
coresight: etm3x: Cleanup ETMTECR1 register accesses
coresight: etm4x: Cleanup TRCACATRn register accesses
coresight: etm4x: Cleanup TRCSSCCRn and TRCSSCSRn register accesses
coresight: etm4x: Cleanup TRCSSPCICRn register accesses
coresight: etm4x: Cleanup TRCBBCTLR register accesses
coresight: etm4x: Cleanup TRCRSCTLRn register accesses
.../coresight/coresight-etm3x-core.c | 2 +-
.../coresight/coresight-etm3x-sysfs.c | 2 +-
.../coresight/coresight-etm4x-core.c | 136 +++++--------
.../coresight/coresight-etm4x-sysfs.c | 180 +++++++++---------
drivers/hwtracing/coresight/coresight-etm4x.h | 122 ++++++++++--
5 files changed, 244 insertions(+), 198 deletions(-)
--
2.28.0
Hi Greg,
Thanks for your review.
On 3/24/2022 8:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Mar 24, 2022 at 08:17:25PM +0800, Mao Jinlong wrote:
>> Use hash length of the source's device name to map to the pointer
>> of the enabled path. Using IDR will be more efficient than using
>> the list. And there could be other sources except STM and CPU etms
>> in the new HWs. It is better to maintain all the paths together.
>>
>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 75 +++++++-------------
>> 1 file changed, 26 insertions(+), 49 deletions(-)
> Your subject line is odd. Please put back the driver subsystem in the
> subject line so that it makes more sense.
I will update the subject in next version.
>
> And how have you measured "more efficient"?
Using IDR would be better than doing a sequential search as there will
be much more device in future.
>
> thanks,
>
> greg k-h
Thanks
Jinlong Mao
Hi Greg,
On 3/25/2022 1:06 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 24, 2022 at 10:23:19PM +0800, Jinlong Mao wrote:
>> Hi Greg,
>>
>> Thanks for your review.
>>
>> On 3/24/2022 8:26 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Mar 24, 2022 at 08:17:25PM +0800, Mao Jinlong wrote:
>>>> Use hash length of the source's device name to map to the pointer
>>>> of the enabled path. Using IDR will be more efficient than using
>>>> the list. And there could be other sources except STM and CPU etms
>>>> in the new HWs. It is better to maintain all the paths together.
>>>>
>>>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-core.c | 75 +++++++-------------
>>>> 1 file changed, 26 insertions(+), 49 deletions(-)
>>> Your subject line is odd. Please put back the driver subsystem in the
>>> subject line so that it makes more sense.
>> I will update the subject in next version.
>>> And how have you measured "more efficient"?
>> Using IDR would be better than doing a sequential search as there will be
>> much more device in future.
> How many "more"? Where does the trade off of speed for complexity help?
> How much faster is this really? You can't claim performance
> improvements without any proof :)
There is about 40 trace sources in our internal device. I believe there
will be more cpu cores, then
there will be more etm sources. IDR here is used to store the path of
both etm
sources and other sources which aren't associated with CPU. Use IDR is
not more complicated
than using list. It will also save the time of searching the path when
coresight_disable.
I tested in internal device. The test case is that enable all the
sources, disable the source one
by one to check the search time.
Use list to store paths:
sh-7687 [005] .... 342.113099: __coresight_disable:
====search path start==== source_0
sh-7687 [005] .... 342.113127: __coresight_disable:
====search path end==== source_0
sh-7693 [005] .... 342.542216: __coresight_disable:
====search path start==== source_1
sh-7693 [005] .... 342.542244: __coresight_disable:
====search path end==== source_1
sh-7699 [005] .... 342.929083: __coresight_disable:
====search path start==== source_2
sh-7699 [005] .... 342.929106: __coresight_disable:
====search path end==== source_2
sh-7711 [005] .... 343.760688: __coresight_disable:
====search path start==== source_3
sh-7711 [005] .... 343.760713: __coresight_disable:
====search path end==== source_3
sh-7717 [005] .... 344.172353: __coresight_disable:
====search path start==== source_4
sh-7717 [005] .... 344.172381: __coresight_disable:
====search path end==== source_4
Use IDR to store paths:
sh-7156 [006] .... 223.294228: __coresight_disable:
====search path start==== source_0
sh-7156 [006] .... 223.294237: __coresight_disable:
====search path end==== source_0
sh-7162 [006] .... 223.690153: __coresight_disable:
====search path start==== source_1
sh-7162 [006] .... 223.690163: __coresight_disable:
====search path end==== source_1
sh-7168 [006] .... 224.110670: __coresight_disable:
====search path start==== source_2
sh-7168 [006] .... 224.110679: __coresight_disable:
====search path end==== source_2
<...>-7180 [006] .... 224.929315: __coresight_disable:
====search path start==== source_3
<...>-7180 [006] .... 224.929324: __coresight_disable:
====search path end==== source_3
<...>-7186 [006] .... 225.343617: __coresight_disable:
====search path start==== source_4
<...>-7186 [006] .... 225.343626: __coresight_disable:
====search path end==== source_4
From the log, Searching the path from the IDR takes about 9us for each
source.
Searching the path from the list takes about 23 ~ 28us for the source.
Use IDR saves much time.
Thanks
Jinlong Mao
>
> thanks,
>
> greg k-h
Hi All,
Couple of questions:
1. Does anyone know of any other software options other than DS-5 for configuring, capturing and viewing data using the ELA-600 ?
2. I could roll my own but I don't think OpenCSD has support for the ELA-600. Correct ?
Thanks in advance
Hugh
-----Original Message-----
From: coresight-request(a)lists.linaro.org <coresight-request(a)lists.linaro.org>
Sent: Thursday 24 March 2022 17:36
To: Hugh O'Keeffe <hugh.okeeffe(a)ashling.com>
Subject: Welcome to the "CoreSight" mailing list
Welcome to the "CoreSight" mailing list!
To post to this list, send your message to:
coresight(a)lists.linaro.org
You can unsubscribe or make adjustments to your options via email by sending a message to:
coresight-request(a)lists.linaro.org
with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You will need your password to change your options, but for security purposes, this password is not included here. If you have forgotten your password you will need to reset it via the web UI.