CoreSight

coresight@lists.linaro.org

9 participants
2378 discussions

by marekzmyslowski

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 > >> > > > > > > >

7 years, 1 month

Point Of Sale Software Users List.

by gemma.white＠collabratesuite.com

<div dir="ltr">Hi, Hope this note finds you well! Would you be interested in Point Of Sale Software Users List? We are a Global Technology User’s List Provider’s with 90 Million Plus data and counting. 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 list of companies using POS software accordingly. Do not hesitate to take the smart step for improving your business. Deliver highly targeted campaign to your customers and prospects using the comprehensive Retail Management (POS) Software user group’s data, drive the right traffic to your website and generate quality leads through targeted b2b marketing. By partnering with us you can obtain an effective email list of Point of Sale software customers, where each record comes with full contact name, complete postal address, mobile telephone number and email addresses, and much more. Please let us know your targeted criteria and geography to provide you with detailed information for your review. Let me know your thoughts! Thanks, Gemma White Senior Database Executive To “opt out” response not interested </div>  <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>

7 years, 1 month

[PATCH v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

by Leo Yan

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

7 years, 1 month

[PATCH 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

by Leo Yan

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

7 years, 1 month

[PATCH 1/4] tests: printf parameter bugfix

by Mike Leach

>From original patchset created-by: Wookey <wookey(a)wookware.org> Signed-off-by: Mike Leach <mike.leach(a)linaro.org> --- decoder/tests/ext_dcd_test_eg/c_api_echo_test/ext_dcd_echo_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/decoder/tests/ext_dcd_test_eg/c_api_echo_test/ext_dcd_echo_test.c b/decoder/tests/ext_dcd_test_eg/c_api_echo_test/ext_dcd_echo_test.c index 32365ef..e2ad045 100644 --- a/decoder/tests/ext_dcd_test_eg/c_api_echo_test/ext_dcd_echo_test.c +++ b/decoder/tests/ext_dcd_test_eg/c_api_echo_test/ext_dcd_echo_test.c @@ -330,7 +330,7 @@ void print_test_cov_results(echo_decoder_t *decoder) if (coverage[TEST_COV_MSGLOG_CB] == TEST_RES_OK) /* check we can use the msg logger for outputting the results */ lib_cb_LogMsg(p_fns, OCSD_ERR_SEV_ERROR, coverage_message); else - printf(coverage_message); + printf("%s", coverage_message); } } -- 2.14.2

7 years, 1 month

[RFC PATCH] perf: Support for Arm A32/T32 instruction sets in CoreSight trace

by Robert Walker

This patch adds support for generating instruction samples from trace of AArch32 programs using the A32 and T32 instruction sets. A32 has a fixed 4 byte instruction size, so the conversion between addresses and instruction counts is handled in the same way as A64. T32 has variable 2 or 4 byte instruction size, so the conversion between addresses and instruction counts requires examination of the instruction bytes. Signed-off-by: Robert Walker <robert.walker(a)arm.com> --- This patch is an initial draft of support for trace of A32 / T32 programs. We need to pass the instruction set for each executed range from the decoder and then use the instruction set information when converting between executed address ranges and instruction counts - for T32 we need to look at the individual instructions to determine if they are 2 or 4 bytes. Regards Rob tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 21 ++++++ tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 8 +++ tools/perf/util/cs-etm.c | 93 +++++++++++++++---------- 3 files changed, 86 insertions(+), 36 deletions(-) diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c index 640af88..fbd356f 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -256,6 +256,7 @@ static void cs_etm_decoder__clear_buffer(struct cs_etm_decoder *decoder) for (i = 0; i < MAX_BUFFER; i++) { decoder->packet_buffer[i].start_addr = 0xdeadbeefdeadbeefUL; decoder->packet_buffer[i].end_addr = 0xdeadbeefdeadbeefUL; + decoder->packet_buffer[i].isa = CS_ETM_ISA_UNKNOWN; decoder->packet_buffer[i].last_instr_taken_branch = false; decoder->packet_buffer[i].exc = false; decoder->packet_buffer[i].exc_ret = false; @@ -285,6 +286,7 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder, decoder->packet_count++; decoder->packet_buffer[et].sample_type = sample_type; + decoder->packet_buffer[et].isa = CS_ETM_ISA_UNKNOWN; decoder->packet_buffer[et].exc = false; decoder->packet_buffer[et].exc_ret = false; decoder->packet_buffer[et].cpu = *((int *)inode->priv); @@ -314,6 +316,25 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder, packet->start_addr = elem->st_addr; packet->end_addr = elem->en_addr; + + switch (elem->isa) { + case ocsd_isa_aarch64: + packet->isa = CS_ETM_ISA_A64; + break; + case ocsd_isa_arm: + packet->isa = CS_ETM_ISA_A32; + break; + case ocsd_isa_thumb2: + packet->isa = CS_ETM_ISA_T32; + break; + case ocsd_isa_tee: + case ocsd_isa_jazelle: + case ocsd_isa_custom: + case ocsd_isa_unknown: + default: + packet->isa = CS_ETM_ISA_UNKNOWN; + } + switch (elem->last_i_type) { case OCSD_INSTR_BR: case OCSD_INSTR_BR_INDIRECT: diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h index 743f5f4..630292e 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h @@ -27,10 +27,18 @@ enum cs_etm_sample_type { CS_ETM_TRACE_ON = 1 << 1, }; +enum cs_etm_isa { + CS_ETM_ISA_UNKNOWN, + CS_ETM_ISA_A64, + CS_ETM_ISA_A32, + CS_ETM_ISA_T32, +}; + struct cs_etm_packet { enum cs_etm_sample_type sample_type; u64 start_addr; u64 end_addr; + enum cs_etm_isa isa; u8 last_instr_taken_branch; u8 exc; u8 exc_ret; diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 1b0d422..004ace3 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -32,14 +32,6 @@ #define MAX_TIMESTAMP (~0ULL) -/* - * A64 instructions are always 4 bytes - * - * Only A64 is supported, so can use this constant for converting between - * addresses and instruction counts, calculting offsets etc - */ -#define A64_INSTR_SIZE 4 - struct cs_etm_auxtrace { struct auxtrace auxtrace; struct auxtrace_queues queues; @@ -494,40 +486,69 @@ static inline void cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq) etmq->last_branch_rb->nr = 0; } -static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet) +static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq, + u64 addr) { + u8 instrBytes[2]; + cs_etm__mem_access(etmq, addr, 2, instrBytes); + return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2; +} + +static inline u64 cs_etm__last_executed_instr(struct cs_etm_queue *etmq) { + const struct cs_etm_packet *packet = etmq->prev_packet; + /* * The packet records the execution range with an exclusive end address - * - * A64 instructions are constant size, so the last executed - * instruction is A64_INSTR_SIZE before the end address - * Will need to do instruction level decode for T32 instructions as - * they can be variable size (not yet supported). */ - return packet->end_addr - A64_INSTR_SIZE; + if (packet->isa == CS_ETM_ISA_T32) { + /* + * T32 instructions can be either 2 or 4 bytes + */ + if (packet->end_addr - packet->start_addr == 2) + /* Only one 2 byte instruction in packet*/ + return packet->start_addr; + else if (cs_etm__t32_instr_size(etmq, packet->end_addr) == 4) + return packet->end_addr - 4; + else + return packet->end_addr - 2; + } else { + /* Assume a 4 byte instruction size (A32/A64) */ + return packet->end_addr - 4; + } } -static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet) +static inline u64 cs_etm__instr_count(struct cs_etm_queue *etmq, + const struct cs_etm_packet *packet) { - /* - * Only A64 instructions are currently supported, so can get - * instruction count by dividing. - * Will need to do instruction level decode for T32 instructions as - * they can be variable size (not yet supported). - */ - return (packet->end_addr - packet->start_addr) / A64_INSTR_SIZE; + if (packet->isa == CS_ETM_ISA_T32) { + u64 addr = packet->start_addr; + u64 count = 0; + while (addr != packet->end_addr) { + addr += cs_etm__t32_instr_size(etmq, addr); + count++; + } + return count; + } else { + /* Assume a 4 byte instruction size (A32/A64) */ + return (packet->end_addr - packet->start_addr) / 4; + } } -static inline u64 cs_etm__instr_addr(const struct cs_etm_packet *packet, +static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq, + const struct cs_etm_packet *packet, u64 offset) { - /* - * Only A64 instructions are currently supported, so can get - * instruction address by muliplying. - * Will need to do instruction level decode for T32 instructions as - * they can be variable size (not yet supported). - */ - return packet->start_addr + offset * A64_INSTR_SIZE; + if (packet->isa == CS_ETM_ISA_T32) { + u64 addr = packet->start_addr; + while (offset > 0) { + addr += cs_etm__t32_instr_size(etmq, addr); + offset--; + } + return addr; + } else { + /* Assume a 4 byte instruction size (A32/A64) */ + return packet->start_addr + offset * 4; + } } static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq) @@ -547,7 +568,7 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq) etmq->last_branch_pos -= 1; be = &bs->entries[etmq->last_branch_pos]; - be->from = cs_etm__last_executed_instr(etmq->prev_packet); + be->from = cs_etm__last_executed_instr(etmq); be->to = etmq->packet->start_addr; /* No support for mispredict */ be->flags.mispred = 0; @@ -700,7 +721,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq) event->sample.header.misc = PERF_RECORD_MISC_USER; event->sample.header.size = sizeof(struct perf_event_header); - sample.ip = cs_etm__last_executed_instr(etmq->prev_packet); + sample.ip = cs_etm__last_executed_instr(etmq); sample.pid = etmq->pid; sample.tid = etmq->tid; sample.addr = etmq->packet->start_addr; @@ -858,7 +879,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq) int ret; u64 instrs_executed; - instrs_executed = cs_etm__instr_count(etmq->packet); + instrs_executed = cs_etm__instr_count(etmq, etmq->packet); etmq->period_instructions += instrs_executed; /* @@ -888,7 +909,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq) * executed, but PC has not advanced to next instruction) */ u64 offset = (instrs_executed - instrs_over - 1); - u64 addr = cs_etm__instr_addr(etmq->packet, offset); + u64 addr = cs_etm__instr_addr(etmq, etmq->packet, offset); ret = cs_etm__synth_instruction_sample( etmq, addr, etm->instructions_sample_period); @@ -936,7 +957,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq) * Use the address of the end of the last reported execution * range */ - u64 addr = cs_etm__last_executed_instr(etmq->prev_packet); + u64 addr = cs_etm__last_executed_instr(etmq); err = cs_etm__synth_instruction_sample( etmq, addr, -- 2.7.4

7 years, 1 month

Re: Upstream support for ETM strobing

by Mathieu Poirier

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.

7 years, 1 month

RE: IBM lotus-accounts

by Chris Samuel

Hi, Any updates to below emails,.? Regards Chris From: Chris Samuel [mailto:chris.samuel@lead-marketings.com] Sent: Thursday, April 05, 2018 10:40 AM To: 'coresight(a)lists.linaro.org' Subject: RE: IBM lotus-accounts Hi, Any updates to below emails,.? Awaiting your kind response for regarding my previous email. If it makes sense to talk, please let me know how your calendar looks. I would appreciate if you could pass along my details to the appropriate person if you don't handle this. Do you have any other requirement kindly let me know your exact target industry and target audience and target location, we will provide the exact cost and counts with many more .... Regards, Chris From: Chris Samuel [mailto:chris.samuel@lead-marketings.com] Sent: Tuesday, April 03, 2018 3:40 PM To: 'coresight(a)lists.linaro.org' Subject: IBM lotus-accounts Hi, A quick check to see if you would you be interested to acquire updated Slack, IBM Lotus Domino, IBM Lotus Notes, LogMeIn, Microsoft SharePoint, Accounts with verified email and phone numbers. kindly let me know your exact target industry and target audience and target location, we will provide the exact database counts with cost and many more.... Appreciate your time and look forward to your response. Best Regards, Chris, Marketing Executive, If you do not want to receive from us then reply back "Unsubscribe" as a Subject Line.

7 years, 2 months

RE: California Dental Association - Spring - CDA 2018 Attendees list

by Rick Forster

Hello, I hope you're doing well! I am following up with you on the below since I have not heard back from you. Please let me know if you would like to get more information on the same. Looking forward to hearing from you. Warm Regards, Rick Forster From: Rick Forster [mailto:rick.forster@attendeeinfo.com] Sent: 24 April 2018 09:23 To: 'coresight(a)lists.linaro.org' Subject: California Dental Association - Spring - CDA 2018 Attendees list Hello, I hope you are the right person to discuss about California Dental Association - Spring - CDA May 2018 Attendees Info? California Dental Association - Spring - CDA 2018 Attendees list of 18,900 contacts with complete contact details and verified email addresses info will be provided for unlimited usage. Interested? Email me back, I'd love to provide more information. Thank you. Regards, Rick Foster Demand Generation Executive. If you do not wish to receive future emails from us, please reply as "opt-out"

7 years, 2 months

California Dental Association - Spring - CDA 2018 Attendees list

by Rick Forster

Hello, I hope you are the right person to discuss about California Dental Association - Spring - CDA May 2018 Attendees Info? California Dental Association - Spring - CDA 2018 Attendees list of 18,900 contacts with complete contact details and verified email addresses info will be provided for unlimited usage. Interested? Email me back, I'd love to provide more information. Thank you. Regards, Rick Foster Demand Generation Executive. If you do not wish to receive future emails from us, please reply as "opt-out"

7 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight