On Fri, 24 Mar 2017 10:42:51 +0000 Mike Leach mike.leach@linaro.org wrote:
Hi Km
On 24 March 2017 at 00:31, Kim Phillips kim.phillips@arm.com wrote:
On Thu, 16 Mar 2017 22:36:08 +0000 Mike Leach mike.leach@linaro.org wrote:
This thread is now getting a bit unwieldy with all the inlined extensive logging.
the idea was that one could cut out all irrelevant pieces, leaving relevant ones intact for an in-line, context-sensitive response. Thus the 'no top posting/always trim your replies' recommendations for replying on development lists like these.
Also we are considerably off topic - no longer about perf inject, but more about simply getting the CS infrastructure working in your environment.
oh, you're referring to the title, which remains the ultimate goal, and I consider the getting-there experience still relevant (since, e.g., the AutoFDO documentation area doesn't explicitly point out what sink was enabled if any, and so on). Btw, an alternate means of splitting threads is to take a message and reply twice - once with one new title 'Subject: new theme A (was: <old title>)' and addressing that theme there, then another with a similar change in the title for theme B. I thought this thread was doing well since we were both carrying the unable to mmap and hard lockup problems along, and I had no proof they weren't related.
At this point it appears that google mail is not correctly showing all the previous mail so I cannot all the answers at your questions.
Google's webmail interface wouldn't be my first choice for an open source developer's mailer. IIRC, linaro had IMAP/SMTP instructions for hooking up your account to real mailers like thunderbird, mutt, etc. I use sylpheed, e.g., and have no problem continuing threads like these.
Nor mine, but as I am using my linaro.org mail, ARM IT will only allow web access inside the ARM network to servers other than official ARM ones. Therefore the imap server for linaro is blocked inside ARM.
Linaro uses gmail, last I knew. ARM now uses microsoft's cloud, and allows non-web based access to that, so I think there's a bug in the IT dept. policy if they think allowing microsoft access
Performance counter stats for 'taskset -c 2 /home/kim/git/OpenCSD/tools/perf/perf record -o perf-etm.data -e cs_etm//u --per-thread taskset -c 2 ./sort-O3':
6568.653900 task-clock (msec) # 0.496 CPUs utilized 181 context-switches # 0.028 K/sec 1 cpu-migrations # 0.000 K/sec 1,950 page-faults # 0.297 K/sec <not counted> cycles (0.00%) <not counted> instructions (0.00%) <not counted> branches (0.00%) <not counted> branch-misses (0.00%) 13.235000365 seconds time elapsedroot@juno:~# /home/kim/git/OpenCSD/tools/perf/perf stat taskset -c 2 ./sort-O3Bubble sorting array of 30000 elements 5364 ms
Performance counter stats for 'taskset -c 2 ./sort-O3':
5365.715560 task-clock (msec) # 1.000 CPUs utilized 3 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 126 page-faults # 0.023 K/sec <not counted> cycles (0.00%) <not counted> instructions (0.00%) <not counted> branches (0.00%) <not counted> branch-misses (0.00%) 5.366555299 seconds time elapsedIs this the expected overhead, given the (85 - 82) / 85 = 3.5% success rate of capturing and storing the trace data? I'd expect a lot more than 5MB of trace for the incurred 2.5x execution time (8 seconds in this case). I can't help but imagine those funnel printk's have a negative influence in the area...
The "loss" in this case is a flag indicator that the 64k ETF is wrapping. So there is some data loss, but you do get a full 64k buffer each time. You should get less loss if you use the ETR.
combining that with your comment from the other thread:
Don't enable the sink using sysfs, specify the sink on the perf command line and use the up arrow as much as you like.
and searching for etr in the current documentation, I assume you mean I should execute perf like this?:
root@juno:~# taskset -c 2 /home/kim/git/OpenCSD/tools/perf/perf record -o perf-etm.data -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 ./sort-O3 failed to mmap with 12 (Cannot allocate memory) root@juno:~#
it doesn't matter how many times I invoke it, I get the same message (and no hints in dmesg). I've tried without the /u, but still no dice.
Here's the -vvv version:
root@juno:~# taskset -c 2 /home/kim/git/OpenCSD/tools/perf/perf record -vvv -o perf-etm.data -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 ./sort-O3 ------------------------------------------------------------ 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 2528 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 2528 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) root@juno:~#
Thanks,
Kim