S390 only #ifdef

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


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