Re: OProfile-1.2.0-rc1

On 06/28/2017 11:53 AM, William Cohen wrote:
> On 06/26/2017 10:42 AM, Will Schmidt wrote:
>> On Mon, 2017-06-19 at 11:08 -0400, William Cohen wrote:
>>> There have been a number of improvements checked into the OProfile git repo.  It would be good to have those into an official release.  I have made a release candidate and it would be good to test this out on various platforms.
>>>
>>> URL:
>>> https://sourceforge.net/projects/oprofile/files/oprofile/oprofile-1.2.0rc1/oprofile-1.2.0rc1.tar.gz/download
>>>
>>
>> I grabbed and did a build/run across a small assortment of power
>> systems.   (power7,power8LE,power8BE), test suite runs clean. 
>> (Also looks good on pre-ga P9)
>> 			=== oprofile Summary ===
>> 	
>> 	# of expected passes		78
>>
>> One error in 'make check'.  (also see this on my x86 laptop).
>> I suspect not a big deal, but in case... :-)
>>
>> 	FAIL: load_events_files_tests
>>
>> 	um zero is not used
>>
>> A quick peek via gdb suggests this is occurring when trying to parse the
>> events files for CPU_CORE_I7, down the op_events(cpu_type) path.  If I
>> force that test to pass via setting err=0 in gdb, it occurs again on
>> CPU_NEHALEM.
>>
>> Breakpoint 1, op_events (cpu_type=CPU_CORE_I7) at op_events.c:724
>> 724	{
>> $60 = CPU_CORE_I7
>> um zero is not used
>>
>> Breakpoint 1, op_events (cpu_type=CPU_NEHALEM) at op_events.c:724
>> 724	{
>> $63 = CPU_NEHALEM
>> um zero is not used
>>
>>
>> thanks
>> -Will (Schmidt)
> 
> Hi Will,
> 
> I took a look at this failure from "make check".  This is due to the events/i386/arch_perfmon/unit_masks having the unit mask zero, but it not being used in nahelem for the events. i386/nehalem/events has:
> 
> #event:0x3c counters:0,1,2,3 um:zero minimum:6000 name:CPU_CLK_UNHALTED : Clock cycles when not halted
> event:0x3c counters:0,1,2,3 um:one minimum:6000 name:UNHALTED_REFERENCE_CYCLES : Unhalted reference cycles
> 
> The nahelem events are included in the i386/core_i7 events. Thus, it also suffers from the same problem.  This appears to be relatively harmless.  However, it does cause the load_events_files_tests test to abort so processors after core_i7 (including nehalem) are not check for event sanity.  I manually set err=0 after each of the reports of the unused mask and didn't see any other problems.
> 
> -Will Cohen

The attached patch should address the test failure.  Does that seem like a reasonable fix?  -Will

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
oprofile-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oprofile-list

From 9bd80d439b63dd1b3da9b066f9df05d5e67e3112 Mon Sep 17 00:00:00 2001
From: William Cohen <[email protected]>
Date: Wed, 28 Jun 2017 12:01:57 -0400
Subject: [PATCH] Address unused unit_mask for i386/nehalem and i386/core_i7

The nehalem and core_i7 processors events differ slightly from the
i386/arch_perfmon events and do not use the zero unit mask.  This
difference caused "make check" load_events_files_tests to fail because
the zero unit mask included from i386/arch_perfmon was not used.  To
avoid this failure the used unit masks have been pulled into the
i386/nehalem/unit_masks and the zero unit was not included.
---
 events/i386/nehalem/unit_masks | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/events/i386/nehalem/unit_masks b/events/i386/nehalem/unit_masks
index def2e69..1569d54 100644
--- a/events/i386/nehalem/unit_masks
+++ b/events/i386/nehalem/unit_masks
@@ -2,7 +2,12 @@
 # Unit masks for the Intel "Nehalem" micro architecture
 # (Intel Core i7 "Bloomfield"; Xeon 75xx)
 #
-include:i386/arch_perfmon
+name:one type:mandatory default:0x1
+	0x1 No unit mask
+name:x41 type:mandatory default:0x41
+	0x41 No unit mask
+name:x4f type:mandatory default:0x4f
+	0x4f No unit mask
 name:sb_forward type:mandatory default:0x01
 	0x01 extra: any Counts the number of store forwards
 name:load_block type:bitmask default:0x01
-- 
2.9.4