Re: Announcement: Release Candidate 1 for OProfile 1.0.0

On 08/29/2014 11:02 AM, William Cohen wrote:
> On 08/29/2014 09:28 AM, Maynard Johnson wrote:
>> On 08/28/2014 08:30 PM, William Cohen wrote:
>>> 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
>>>
>>> I did a git bisection and narrowed the problem patch to:
>>>
>>> $ git bisect bad
>>> 3f93a3b306875ff5591149a23034fed92a0844d7 is the first bad commit
>>> commit 3f93a3b306875ff5591149a23034fed92a0844d7
>>> Author: Maynard Johnson <[email protected]>
>>> Date:   Thu Aug 7 15:58:23 2014 -0500
>>>
>>>     Exclude collecting hypervisor samples for default event
>>
>> Yeah, as I suspected.  Will, I just posted a patch ("[PATCH] Back out recent change to
>> exclude hypervisor samples and counts") to fix this.  Can you please try it out.
>> Hopefully you can give me feedback on it today.  I'd like to put out a release candidate 2
>> today, since I'll be out of the office all next week.
>>
>> Thanks!
>> -Maynard
> 
> Hi Maynard,
> 
> I built rpms from the current oprofile git repo and included the patch (http://koji.fedoraproject.org/koji/taskinfo?taskID=7485311).  I reran the tests on the cortex a15, amd family 10, and ivybridge machine and verified there weren't any changes in the test results.  For Fedora arm cortex a9 there was some improvements.  All the cycle-check-ocount tests pass now and more of the other tests pass.  However, there are still more failures on the f20 cortex a9 than the other machine, most often a "Non-zero count for workload ...". I have attached the output of tests for the cortex a9.
Will,
Thanks for testing the patch.  I looked at the testsuite log file you had attached, and all the errors are explainable as testsuite issues or the path of the operf binary messing up how the testsuite locates the opreport.xsd file.  To be specific, the testsuite issues are:
	1. In the failing oprofile-ocount test, we fiddle with the modes (trying user only,
	   kernel only, and then both -- comparing the "both" output to the cumulative results
	   user-only and kernel-only tests); and since mode exclusion is not supported on that
	   processor, all 3 tests fail. (But why does the testsuite apparently work on A15?
	   Is the non-support of mode exclusion really just for A9?)
	2. Using INST_RETIRED on Coretex A9 where that event is not implemented.

Soooo . . . I will commit the patch that backs out the hypervisor exclusion, and then will put out a new 1.0.0 release candidate.

As I mentioned earlier, I'll be away all next week, so if anyone would like to make some fixes to the testsuite to avoid the two issues listed above, please be my guest.  :-)

-Maynard

> 
> -Will
> 


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/