From: William C. <wc...@re...> - 2014-08-29 03:11:44
|
On 08/28/2014 04:47 PM, Maynard Johnson wrote: > On 08/28/2014 11:11 AM, William Cohen wrote: >> On 08/26/2014 11:56 AM, Maynard Johnson wrote: >>> On 08/15/2014 10:54 AM, Maynard Johnson wrote: >>>> We are pleased to announce OProfile 1.0.0 Release Candidate 1. You can download this release at: >>>> http://sourceforge.net/projects/oprofile/files/oprofile/oprofile-1.0.0-rc1/ >>>> >>>> Please download and test this release candidate, and send your feedback by replying to this message. Please include your hardware platform and Linux distribution information in your reply. >>> >>> Fellow oprofile architecture maintainers, >>> Please test the oprofile 1.0.0 RC1 and let me know your results. FYI . . . Due to the >>> Java profiling bug reported this week by Brian Hall, I will be incorporating a fix into >>> the next 1.0.0 tar file I make available. If more fixes are needed, I will put out an >>> RC2, otherwise I'll make it GA. Either way, I'd like to put out the next tar file by >>> the end of the week. Thanks! >>> >>> -Maynard >>>> >>>> Thanks. >>>> -Maynard Johnson >> >> Hi Maynard, >> >> I built a rpm using the latest git repo tarball and have been testing that out on a number of different platforms. >> >> There are a number of xml failures in the test results (footnotes (1) and (2)). Have anyone else observed that? Or is this a local build issue? >> >> I also had some issues with the tests running on arm cortex-a9. The perf utility works on the machine but operf and ocount are not. This seems to be specific to the cortex a9 machine things work on a cortex a15 machine. >> >> # operf --events INST_RETIRED:500000:0:1:1,CPU_CYCLES:500000:0:1:1, workloads/thread_src/thread_bin >> perf_event_open failed with Operation not supported >> Caught runtime_error: Internal Error. Perf event setup failed. >> Error running profiler >> > This smells very familiar. Looking at kernel code (arch/arm/kernel/perf_event.c), I see the following: > > /* > * Check whether we need to exclude the counter from certain modes. > */ > if ((!armpmu->set_event_filter || > armpmu->set_event_filter(hwc, &event->attr)) && > event_requires_mode_exclusion(&event->attr)) { > pr_debug("ARM performance counters do not support " > "mode exclusion\n"); > return -EOPNOTSUPP; > } > > I've made changes to oprofile recently so that hypervisor events would be excluded by default, > since we currently have nothing in our display formats to indicate hypervisor samples and nothing > in our event specification (passed to operf and ocount) to either include or exclude hypervisor > events. This bit our s390 friends, and we had to add #ifdef __s390__ in > libperf_events/operf_counter.cpp:221 and pe_counting/ocount_counter.cpp:72. > > *Will C*, can you please try to add '#ifdef __arm__' in the same two places and see if the oprofile > testsuite works then. Perhaps I should back out the change I made to exclude hypervisor events. > The issue is that on systems where mode exclusion *is* supported, and where the system is running > on top of a hypervisor, doing something like 'ocount -e CYCLES:0:0:1' ends up counting *both* userspace > and hypervisor events and the output of ocount does not separate them. A similar issue occurs with operf, > but the problem is not quite so pronounced, since opreport typically cannot be resolve hypervisor sample > addresses symbols. > > > -Maynard > > -Maynard > [snip] > Hi Maynard, I tried modifying the #ifdef mentioned earlier today, but that didn't seem to make a difference. Why does the code only handle the s390? RHEL builds code for s390x and ships that version in the distributions. Should the #ifdef also do the same for s390x builds? -Will |