This patch updates the documentation with a summary of
all necessary steps to be followed for performing afdo
optimization
Signed-off-by: Andrea Brunato <andrea.brunato(a)arm.com>
---
decoder/tests/auto-fdo/autofdo.md | 40 +++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/decoder/tests/auto-fdo/autofdo.md b/decoder/tests/auto-fdo/autofdo.md
index 69ed152..b28b645 100644
--- a/decoder/tests/auto-fdo/autofdo.md
+++ b/decoder/tests/auto-fdo/autofdo.md
@@ -433,10 +433,50 @@ sudo ./set_strobing.sh 5000 10000
perf record -e cs_etm/@tmc_etr0/u --per-thread -- <your app>"
perf inject -i perf.data -o inj.data --itrace=i100000il
create_llvm_prof -binary=/path/to/binary -profile=inj.data -out=program.llvmprof
+clang -O2 -fprofile-sample-use=program.llvmprof -o program program.c
```
Use `create_gcov` for gcc.
+## High Level Summary for recoding on Arm board and decoding on different host
+
+1. (on Arm board)
+
+ sudo ./set_strobing.sh 5000 10000
+ perf record -e cs_etm/@tmc_etr0/u --per-thread -- <your app>.
+ If you specify `-N, --no-buildid-cache`, perf will just take care of recording the target binary and nothing will be copied.<br> If you don't specify it, any recorded dynamic library will be copied to ~/.debug in the board.
+
+2. (on Arm board) `perf archive` which saves all the found libraries in a tar (internally, it looks into perf.data file and performs a lookup using perf-buildid-list --with-hits)
+3. (on host) `scp` to copy perf.data and the .tar file generated from `perf archive`.
+4. (on host) Run `tar xvf perf_data.tar.bz2 -C ~/.debug` to populate the buildid-cache
+5. (on host) Double check the setup is correct:
+
+ a. `perf buildid-list -i perf.data` gives you the list of dynamic libraries buildids whose trace has been recorded and saved in perf.data.
+ b. `perf buildid-cache --list` lists the dynamic libraries in the buildid cache that will be used by `perf inject`.
+ Make sure the output of (a) and (b) overlaps as in buildid value for those binaries you are interested into optimizing with afdo.
+
+6. (on host) `perf inject -i perf.data -o inj.data --itrace=i100000il` will check for the dynamic libraries using the buildid inside the buildid-cache and post-process the trace.<br> buildids have to be the same, otherwise it won't be possible to post-process the trace.
+
+7. (on host) `create_llvm_prof -binary=/path/to/binary -profile=inj.data -out=program.llvmprof` takes the output from perf-inject and tranforms it into a format that the compiler can read.
+8. (on host) `clang -O2 -fprofile-sample-use=program.llvmprof -o program program.c` to make clang use the produced profile.<br>
+ If you are confident enough that your profile is accurate, you can add the `-fprofile-sample-accurate` flag, which will penalize all the callsites without corresponding profile, marking them as cold.
+
+If you are using the same host for both building the binary to be traced and re-building it with afdo:
+
+1. You won't need to copy back any dynamic libraries from the board (since you already have them), and can use `--no-buildid-cache` when recording
+2. You have to make sure the relevant dynamic libraries to be optimized are present in the buildid-cache.
+
+You can easily add a dynamic library manually into the build-id cache by running:
+
+`perf buildid-cache --add <path/to/library/or/binary> -vvv`
+
+You can easily check what is currently contained in you buildid-cache by running:
+
+`perf buildid-cache --list`
+
+You can check the buildid of a given binary/dynamic library:
+
+`file <path/to/dynamic/library>`
## References
--
2.17.1
Allow to build coresight as modules. This gives developers the feasibility to
test their code without reboot.
This series is based on below two series.
- "coresight: allow to build components as modules"
https://lkml.org/lkml/2018/6/5/989
- "coresight: make drivers modular"
https://lkml.org/lkml/2020/1/17/468
Change from v1:
Use try_module_get() to avoid module to be unloaded when device is used
in active trace session. (Mathieu P)
Change from above two series.
This series adds the support to dynamically remove module when the device in
that module is enabled and used by some trace path. It disables all trace
paths with that device and release the trace path.
Kim Phillips (7):
coresight: use IS_ENABLED for CONFIGs that may be modules
coresight: allow etm3x to be built as a module
coresight: allow etm4x to be built as a module
coresight: allow etb to be built as a module
coresight: allow tpiu to be built as a module
coresight: allow tmc to be built as a module
coresight: allow funnel and replicator drivers to be built as modules
Mian Yousaf Kaukab (4):
coresight: export global symbols
coresight: remove multiple init calls from funnel driver
coresight: remove multiple init calls from replicator driver
coresight: tmc-etr: add function to register catu ops
Tingwei Zhang (9):
coresight: cpu_debug: add module name in Kconfig
coresight: cpu_debug: define MODULE_DEVICE_TABLE
coresight: add coresight prefix to barrier_pkt
Allow to build coresight-stm as a module, for ease of development.
coresight: cti: add function to register cti associate ops
coresight: allow cti to be built as a module
coresight: allow catu drivers to be built as modules
coresight: add try_get_module() in coresight_grab_device()
coresight: allow the coresight core driver to be built as a module
drivers/hwtracing/coresight/Kconfig | 54 ++++++++--
drivers/hwtracing/coresight/Makefile | 20 ++--
drivers/hwtracing/coresight/coresight-catu.c | 37 ++++++-
drivers/hwtracing/coresight/coresight-catu.h | 2 -
.../{coresight.c => coresight-core.c} | 101 +++++++++++++++---
.../hwtracing/coresight/coresight-cpu-debug.c | 2 +
.../{coresight-cti.c => coresight-cti-core.c} | 46 +++++++-
drivers/hwtracing/coresight/coresight-etb10.c | 22 +++-
.../hwtracing/coresight/coresight-etm-perf.c | 9 +-
.../hwtracing/coresight/coresight-etm-perf.h | 5 +-
...resight-etm3x.c => coresight-etm3x-core.c} | 27 ++++-
...resight-etm4x.c => coresight-etm4x-core.c} | 31 +++++-
.../hwtracing/coresight/coresight-funnel.c | 62 ++++++++++-
.../hwtracing/coresight/coresight-platform.c | 1 +
drivers/hwtracing/coresight/coresight-priv.h | 24 ++---
.../coresight/coresight-replicator.c | 63 ++++++++++-
drivers/hwtracing/coresight/coresight-stm.c | 20 +++-
.../{coresight-tmc.c => coresight-tmc-core.c} | 19 +++-
.../hwtracing/coresight/coresight-tmc-etf.c | 2 +-
.../hwtracing/coresight/coresight-tmc-etr.c | 21 +++-
drivers/hwtracing/coresight/coresight-tmc.h | 3 +
drivers/hwtracing/coresight/coresight-tpiu.c | 19 +++-
include/linux/coresight.h | 2 +-
23 files changed, 518 insertions(+), 74 deletions(-)
rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c} (94%)
rename drivers/hwtracing/coresight/{coresight-cti.c => coresight-cti-core.c} (95%)
rename drivers/hwtracing/coresight/{coresight-etm3x.c => coresight-etm3x-core.c} (97%)
rename drivers/hwtracing/coresight/{coresight-etm4x.c => coresight-etm4x-core.c} (98%)
rename drivers/hwtracing/coresight/{coresight-tmc.c => coresight-tmc-core.c} (96%)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi,
While running perf on some function-heavy code I noticed the ETM return stack
isn't enabled (TRCCONFIGR bit 9). I know that it can easily be enabled with retstack=1,
but have we considered making this the default as we move to simplification of
perf options? It could lead to more efficient profiles and shouldn't be any more
difficult to decode than ETM normally is.
Al
Allow to build coresight as modules. This gives developers the feasibility to
test their code without reboot.
This series is based on below two series.
- "coresight: allow to build components as modules"
https://lkml.org/lkml/2018/6/5/989
- "coresight: make drivers modular"
https://lkml.org/lkml/2020/1/17/468
This series adds the support to dynamically remove module when the device in
that module is enabled and used by some trace path. It disables all trace
paths with that device and release the trace path.
Kim Phillips (7):
coresight: use IS_ENABLED for CONFIGs that may be modules
coresight: allow etm3x to be built as a module
coresight: allow etm4x to be built as a module
coresight: allow etb to be built as a module
coresight: allow tpiu to be built as a module
coresight: allow tmc to be built as a module
coresight: allow funnel and replicator drivers to be built as modules
Mian Yousaf Kaukab (4):
coresight: export global symbols
coresight: remove multiple init calls from funnel driver
coresight: remove multiple init calls from replicator driver
coresight: tmc-etr: add function to register catu ops
Tingwei Zhang (10):
coresight: cpu_debug: add module name in Kconfig
coresight: cpu_debug: define MODULE_DEVICE_TABLE
coresight: add coresight prefix to barrier_pkt
Allow to build coresight-stm as a module, for ease of development.
coresight: cti: add function to register cti associate ops
coresight: allow cti to be built as a module
coresight: allow catu drivers to be built as modules
coresight: disable trace path with device being removed
coresight: allow the coresight core driver to be built as a module
coresight: perf: clean up perf event on device unregister path
drivers/hwtracing/coresight/Kconfig | 54 ++++-
drivers/hwtracing/coresight/Makefile | 20 +-
drivers/hwtracing/coresight/coresight-catu.c | 37 ++-
drivers/hwtracing/coresight/coresight-catu.h | 2 -
.../{coresight.c => coresight-core.c} | 218 ++++++++++++++++--
.../hwtracing/coresight/coresight-cpu-debug.c | 2 +
.../{coresight-cti.c => coresight-cti-core.c} | 46 +++-
drivers/hwtracing/coresight/coresight-etb10.c | 22 +-
.../hwtracing/coresight/coresight-etm-perf.c | 166 ++++++++++++-
.../hwtracing/coresight/coresight-etm-perf.h | 7 +-
...resight-etm3x.c => coresight-etm3x-core.c} | 27 ++-
...resight-etm4x.c => coresight-etm4x-core.c} | 31 ++-
.../hwtracing/coresight/coresight-funnel.c | 62 ++++-
.../hwtracing/coresight/coresight-platform.c | 1 +
drivers/hwtracing/coresight/coresight-priv.h | 28 +--
.../coresight/coresight-replicator.c | 63 ++++-
drivers/hwtracing/coresight/coresight-stm.c | 20 +-
.../{coresight-tmc.c => coresight-tmc-core.c} | 19 +-
.../hwtracing/coresight/coresight-tmc-etf.c | 2 +-
.../hwtracing/coresight/coresight-tmc-etr.c | 21 +-
drivers/hwtracing/coresight/coresight-tmc.h | 3 +
drivers/hwtracing/coresight/coresight-tpiu.c | 19 +-
include/linux/coresight.h | 2 +-
kernel/events/core.c | 1 +
24 files changed, 796 insertions(+), 77 deletions(-)
rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c} (87%)
rename drivers/hwtracing/coresight/{coresight-cti.c => coresight-cti-core.c} (95%)
rename drivers/hwtracing/coresight/{coresight-etm3x.c => coresight-etm3x-core.c} (97%)
rename drivers/hwtracing/coresight/{coresight-etm4x.c => coresight-etm4x-core.c} (98%)
rename drivers/hwtracing/coresight/{coresight-tmc.c => coresight-tmc-core.c} (96%)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Bonjour
Je contacte au nom du fabricant de savons, liquides et gels pour la désinfection des mains et les produits de nettoyage.
Je voudrais vous offrir des produits de désinfection inodores qui nettoient et désinfectent efficacement la peau, éliminant les virus et les bactéries de vos mains. Les produits de désinfection sont destinés à un usage général et professionnel (hôpitaux, salles de traitement, laboratoires et autres).
Nous proposons également des savons liquides efficaces avec une large gamme de parfums, gels douche, shampooings et revitalisants capillaires, et des détergents concentrés qui se distinguent sur le marché avec des performances élevées.
Nos produits sont sans danger pour tous les types de peau, destinés à un usage quotidien, ils ne contiennent ni silicones ni parabènes.
En raison du bon rapport qualité-prix, les cosmétiques et les produits de lavage sont très populaires sur les marchés européens.
Puis-je présenter une offre?
Cordialement
Cecylia Lazar
Responsable du développement commercial
Good day to all,
>From an architecture point of view is it fair to assume there can be
only one timestamp generator per system or there can be more,
something like one per CPU cluster? Either way, is the current
practice expected to continue or there are plans to move to different
design standards?
Thanks,
Mathieu
This patchset introduces initial concepts in CoreSight complex configuration
support - the device "feature", which is a method of programming the device
to perform a specific function.
A built-in feature is provided - the ETM strobing function, which programs the
ETM to switch trace on and off in a specific mark / space ratio to effectively
sample the program being traced. This feature is essential for the Auto-FDO
flow using CoreSight trace.
Features are declared as a data table, a set of register, resource and parameter
requirements. A feature can then be loaded into a device, when the requirements
are validated. Once loaded a feature can be enabled for a specific trace run.
A feature appears in the sysfs file for the device, as a directory of form
'name.feat', with parameters 'enable', 'description' and any input parameters
that may be used to control the operation.
For example the ETM strobing feature provided has parameters of 'window' and
'period' to control the sampling mark / space ratio. The representation in
sysfs for the ETMv4 is therefore:-
etmX/strobing.feat/
/enable
/window
/period
Future developments will introduce resource management, and allow for the
runtime loading of additional features, and the setting of features across
an entire CoreSight system.
Mike Leach (3):
coresight: etmv4: Fix resource selector constant.
coresight: etmv4: Counter values not saved on disable.
coresight: etmv4: Adds initial complex config with ETM4 strobe
feature.
drivers/hwtracing/coresight/Makefile | 7 +-
.../hwtracing/coresight/coresight-config.c | 380 ++++++++++++++++++
.../hwtracing/coresight/coresight-config.h | 156 +++++++
.../hwtracing/coresight/coresight-etm4x-cfg.c | 325 +++++++++++++++
.../hwtracing/coresight/coresight-etm4x-cfg.h | 29 ++
.../coresight/coresight-etm4x-sysfs.c | 3 +
drivers/hwtracing/coresight/coresight-etm4x.c | 24 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 4 +-
drivers/hwtracing/coresight/coresight.c | 1 +
include/linux/coresight.h | 2 +
10 files changed, 925 insertions(+), 6 deletions(-)
create mode 100644 drivers/hwtracing/coresight/coresight-config.c
create mode 100644 drivers/hwtracing/coresight/coresight-config.h
create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
--
2.17.1
Dears,
I am beginner of using opencsd-perf to study the coresight.
My testing platform is Qcom smart phone (SDM845).
I've successful build the opencsed lib and perf-opencsd (both are master
branch)
https://github.com/Linaro/OpenCSDhttps://github.com/Linaro/perf-opencsd
I can find some devices name like these, ( when executing `ls
/sys/bus/coresight/devices/`)
..., coresight-stm, coresight-tmc-etf, coresight-tmc-etr,
coresight-ssc-etm0, ...
However, when I using the commands, I got the error.
1. perfcsd record -e cs_etm/coresight-tmc-etf/ --per-thread ls
==> event syntax error: 'cs_etm/coresight-tmc-etf/' \___ unknown term
2. perfcsd record -e cs_etm/@coresight-tmc-etf/ --per-thread ls
==> event syntax error: 'cs_etm/coresight-tmc-etf/' \___ parser error
I've tried any solutions as many as possible, but I still cannot solve this
problem.
Does perf-opencsd support the android?
Can you help me?
Thank you very much.
Eric