Hello Mathieu,
Thank for the config file. It works. I was able to build the OpenCSD kernel (form the perf-opencsd-master branch) and install on the USB (I used the ArchLinuxARM-aarch64-latest.tar.gz). I also built the perf tool (make -C tools/perf). Everything is booting but the perf has some issues:
[root@alarm home]# ./perf record -vvv -e cs_etm/(a)20070000.etr/u --per-thread uname
map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir
Problems setting modules path maps, continuing anyway...
------------------------------------------------------------
perf_event_attr:
type 8
size 112
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
enable_on_exec 1
sample_id_all 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 4
------------------------------------------------------------
perf_event_attr:
type 1
size 112
config 0x9
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
mmap 1
comm 1
enable_on_exec 1
task 1
sample_id_all 1
mmap2 1
comm_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 5
mmap size 528384B
AUX area mmap length 4194304
perf event ring buffer mmapped per thread
failed to mmap AUX area
failed to mmap with 12 (Cannot allocate memory)
I fixed the "map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir" issue by adding appropriate symbolic link but I still have an issue with the mmap. Any idea what can be wrong here (below limits that I have on my Juno)?
[root@alarm ~]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31798
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31798
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@alarm ~]#
Regards
Marek
W dniu 2017-08-18 16:54:42 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> On 18 August 2017 at 04:22, marekzmyslowski
> <marekzmyslowski(a)poczta.onet.pl> wrote:
> > Hello Mathieu,
> >
> > I've decided that currently I don't need Android. The Linux is enough.
>
> That is probably a better place to start.
>
> > However I have another issue. I've downloaded the perf-opencsd-master branch. I run the config with the ARCH=arm64 and CROSS_COMPLIE=aarch64-linux-gnu- and added support for Versatile board. Then I compiled kernel - everything was OK. Next I built the USB using the following instruction:
> > https://archlinuxarm.org/platforms/armv8/arm/juno (it works fine. The linux boot on the Juno).
> > Next I copied the Image file and juno.dtb into the USB but it doesn't boot. It hangs here:
> >
> > initrd: address 0x0
> > initrd: length 0x0
> > PEI 1132 ms
> > DXE 1695 ms
> > BDS 368934875444 ms
> > BDS 368934873448 ms
> > BDS 1535 ms
> > Total Time = 368934871781 ms
> >
> > linux: address 0x80080000
> > linux: length 0x1150200
> > fdt: address 0x9FE00000
> > fdt: length 0x5F54
> >
> > Any idea what I'm doing wrong? Any help will be appreciated (I'm so close to have Juno + CoreSight + perf :) )
>
> I can't help you with booting the board itself. The best I can do is
> advise to use u-boot instead of UEFI and give you my kernel .config
> file (attached). For the rest there is plenty of documentation out
> there.
>
> >
> > Regards
> > Marek
> >
> > W dniu 2017-08-16 23:08:04 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> >> Hello Marek,
> >>
> >> Please CC the CoreSight mailing list when asking questions as someone
> >> else may also be able to answer.
> >>
> >> First and foremost I advise using the official CoreSight kernel found
> >> on the openCSD site [1] rather than my personal branch [2] - you
> >> never know what you'll get with the latter.
> >>
> >> That being said the CoreSight kernel on the openCSD site is not an
> >> Android kernel - it is simply a mainline kernel supplemented with
> >> patches that haven't made their way to mainline yet. You will have to
> >> either add the android patches to the CoreSight kernel or the other
> >> way around (CoreSight patches on android kernel).
> >>
> >> Android user space is also different and does not include the
> >> perf-tools. You will have to add them manually along with the
> >> dependencies they require. I haven't gone through that process and as
> >> such can't advise more on that portion.
> >>
> >> Get back to me with your questions if the above isn't sufficient.
> >>
> >> Best regards,
> >> Mathieu
> >>
> >> [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master
> >> [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/
> >>
> >> On 16 August 2017 at 14:32, marekzmyslowski
> >> <marekzmyslowski(a)poczta.onet.pl> wrote:
> >> > Hello Mathieu,
> >> >
> >> > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12.
> >> > Any help with this will be appreciated :)
> >> >
> >> > Regards
> >> > Marek Zmysłowski
> >>
> >
> >
> >
>
<div dir="ltr"><p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Hi,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Hope this
note finds you well!</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Would you
be interested in <b>Point Of Sale Software Users List</b>? We are a Global
Technology
User’s List Provider’s with 90 Million Plus data and counting.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">It is good
if you keep track of all your competitors'
movements and their campaign strategies. But do not make their strategies of
your own; you can never beat them that way. Even if the industry is the
same,
each organization has some specific business goals in mind that requires a
campaign-plan that is different from others. Considering the fact that data
requirement for every marketer will be non-identical as per their campaign
planning, we at first consult with our clients to understand their
strategies
and then tailor personalized <b>list of
companies using POS software </b>accordingly<b>.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Do not
hesitate to take the smart step for improving your
business. Deliver highly targeted campaign to your customers and prospects
using the comprehensive <b>Retail
Management (POS) Software user</b> group’s data, drive the right traffic to
your website and <b>generate quality leads
through targeted b2b marketing.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">By
partnering with us you can obtain an effective email
list of Point of Sale software customers, where each record comes with
<b>full contact name, complete postal address,
mobile telephone number and email addresses, and much more.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Please let
us know your targeted criteria and geography to
provide you with detailed information for your review.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Let me
know your thoughts!</span></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Thanks,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><b><span style="color:rgb(31,78,121)">Gemma
White<span></span></span></b></p>
<p class="gmail-MsoNoSpacing"><b><span style="color:rgb(31,78,121)">Senior
Database Executive</span></b></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(156,194,229)">
To “opt out” response not interested<span></span></span></p>
<p class="MsoNormal"><span> </span></p></div>
<p> </p><a style='display: block; margin: 32px 0 40px 0; padding:
10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid
gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and
email marketing software for Gmail.</a>
CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.
This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..69f21de 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -1355,6 +1356,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1387,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.7.4
CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.
This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
tools/perf/util/cs-etm.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..417302c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -266,6 +267,7 @@ static u32 cs_etm__mem_access(struct cs_etm_queue *etmq, u64 address,
if (!thread) {
if (cpumode != PERF_RECORD_MISC_KERNEL)
return -EINVAL;
+
thread = etmq->etm->unknown_thread;
}
@@ -1355,6 +1357,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1388,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.7.4
On 27 April 2018 at 12:24, Robert Walker <Robert.Walker(a)arm.com> wrote:
> Hi,
>
>
>
> Strobing the ETM to reduce the amount of trace data when collecting profiles
> for AutoFDO seems to be working and providing useful optimizations. We’re
> currently working with some proof of concept patches (attached for
> reference) that add parameters to sysfs to configure the strobe period –
> before running perf record, the user must write to these parameters for each
> ETM. This isn’t suitable for production use as it has to be done for each
> ETM and the values persist after the trace session. To get this into
> upstream, we need to have this done by the perf record tool.
>
>
>
> I understand there is work planned to enable more complex ETM configurations
> (such as strobing) from perf, possibly using a file to load register values
> from. Is this still the case, and if so, when is it likely to be done?
Hi Robert,
I am currently working on supporting CPU-wide trace scenarios where I
can start seeing the end of the tunnel. After that my plan was to add
support for ETMv3.x/PTM trace decoding followed by support for N:N
source/sink topology. Part of the latter is to introduce a way to
enable more complex ETM configuration using a configuration file. In
fact I already stumbled on how I want to do that and have a (very)
small prototype that works.
So that is what I had in mind... But it doesn't mean I can't be talked
into changing my priorities. In fact I will gladly do so if we, as a
group, decide it is more important to introduce support for complex
configuration before ETMv3.x/PTM decoding. I personally don't have a
preference, it is simply a matter of deciding what we want to do.
I have CC'ed the coresight mailing list in order to reach a broader
audience. Please speak up if you really have an issue (along with the
rational) with supporting ETM complex configurations before
ETMv3.x/PTM decoding.
Best regards,
Mathieu
>
>
>
> Thanks
>
>
>
> Rob
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.