Re: New version of default unit masks patchkit

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On 06/25/2013 03:22 AM, Suthikulpanit, Suravee wrote:
> Maynard, 
> 
> Thank you for the documentation updates and the commits.  I have tested on AMD system and things look good.  However, "make distcheck" fails and complains about events/i386/ivybridge/unit_masks at line 140 where there is an extra "+" at the beginning of the line.  Once I take this out, it passes the check.
Suravee,
Thanks for thinking of running 'make distcheck' and catching that problem.  I fixed it and just committed the fix.

-Maynard
> 
> Suravee
> 
> -----Original Message-----
> From: Maynard Johnson [mailto:may...@us...] 
> Sent: Monday, June 24, 2013 10:14 AM
> To: Andi Kleen; Suthikulpanit, Suravee
> Cc: oprofile-list
> Subject: Re: New version of default unit masks patchkit
> 
> On 06/19/2013 05:22 PM, Maynard Johnson wrote:
>> On 06/18/2013 06:07 PM, Andi Kleen wrote:
>>> Including Suravee's patch for named default masks, and another patch 
>>> to make all Intel default unit masks unique.
> 
> I've committed the 5-patch set that included patches from Suravee and Andi.  Along with this, I also committed the patch I posted on June 21 to fix problem #4 described below.  And finally, I also committed the doc patch that I posted this morning that corresponds with these changes.
> 
> *Suravee and Andi*
> Please do 'git pull' and test/validate these changes.  Thanks again for working together to get this done!  :-)
> 
> The following open issues are relatively minor, but it would be ideal to have these things taken care of, too. 
> 
> Known open issues
> -----------------
> 1) A few Ivybridge unit masks have duplicate names (I posted a message to *Andi* about this on June 19 -- subject: "Re: [PATCH 2/5] Add empty extra: line to unique Intel events v2").
> 2) Related to #1, we should try to do some automatic sanity tests when parsing the unit mask file to ensure we don't have any duplicate names.  The sanity tests should find such duplicates either during normal run time, but also during 'make distcheck'.
> 3) Some named unit masks have hex values that are duplicates of others in the same UM entry, thus requiring the use of the name to disambiguate them. Specifying one of the hex values that are duplicated should result in an error -- but there are cases where it doesn't.  For example:
>         Here's a properly working example on Sandybridge:
>             [mpjohn@oc1757000783 test-stuff]$ ophelp --check-events int_misc:2000000:0x3
>             Unit mask (0x3) is non unique.
>             Please specify the unit mask using the first word of the description
>        
>         and here's a failing example:
>             [mpjohn@oc1757000783 test-stuff]$ ophelp --check-events l1d_pend_miss:2000000:0x1
>             2 
> 
>        The unit mask descriptions for these two cases are:
> 	=============
> 	BAD:
> 	name:l1d_pend_miss type:bitmask default:pending
>         	0x1 extra: pending Cycles with L1D load Misses outstanding.
> 	        0x1 extra:cmask=1,edge occurences This event counts the number of L1D misses outstanding occurences.
> 
> 	GOOD:
> 	name:int_misc type:bitmask default:0x40
>         	0x40 extra: rat_stall_cycles Cycles Resource Allocation Table (RAT) external stall is sent to Instruction Decode Queue (IDQ) for this thread.
> 	        0x3 extra:cmask=1 recovery_cycles Number of cycles waiting to be recover after Nuke due to all other cases except JEClear.
>         	0x3 extra:cmask=1,edge recovery_stalls_count Edge applied to recovery_cycles, thus counts occurrences.
> 	=============
> 
> 	The obvious difference between these two is that in the BAD case, one of the "extra" fields is a dummy,
> 	but in the GOOD case, both "extra" fields have real extra values associated with them.  I don't know if
> 	this difference is the cause of the problem, but it's certainly a good place to start looking.
> 
> ------------------------------------
> 
> -Maynard
> 
>>>
>> Andi and Suravee,
>> Thank you very much for your collaboration so far in getting the unit mask situation cleaned up.  The issues that I'm aware of that need to be fixed are:
>>
>> 1) User guide and man page updates to reflect the fact that named unit 
>> masks have a "name" field, and "extra" is no longer displayed. (I'll 
>> do this.)
>> 2) A few Ivybridge unit masks have duplicate names (sending separate message about this).
>> 3) Related to #2, we should try to do some automatic sanity tests when parsing the unit mask file to ensure we don't have any duplicate names.  The sanity tests should find such duplicates either during normal run time, but also during 'make distcheck'.
> 
>> 4) Specifying a named unit mask associated with a dummy extra field appears to *always* result in "No sample file found". However, given an appropriate workload, substituting the hex value works OK.  For example:
>> 	On Sandybridge, profiling a testcase that does lots of arithmetic operations on large arrays of numbers
>>         as follows:
>>              operf -e ld_blocks:100000:0x10 ./load_v2
>>         results in about 30,000 samples.  But if I use the "all_block" name for the unit mask instead of '0x10':
>>              operf -e ld_blocks:100000:all_block ./load_v2
>>         the result is "No sample file found".
>> 5) Some named unit masks have hex values that are duplicates of others in the same UM entry, thus requiring the use of the name to disambiguate them. Specifying one of the hex values that are duplicated should result in an error -- but there are cases where it doesn't.  For example:
>>         Here's a properly working example on Sandybridge:
>>             [mpjohn@oc1757000783 test-stuff]$ ophelp --check-events int_misc:2000000:0x3
>>             Unit mask (0x3) is non unique.
>>             Please specify the unit mask using the first word of the 
>> description
>>        
>>         and here's a failing example:
>>             [mpjohn@oc1757000783 test-stuff]$ ophelp --check-events l1d_pend_miss:2000000:0x1
>>             2
>>
>>        The unit mask descriptions for these two cases are:
>> 	=============
>> 	BAD:
>> 	name:l1d_pend_miss type:bitmask default:pending
>>         	0x1 extra: pending Cycles with L1D load Misses outstanding.
>> 	        0x1 extra:cmask=1,edge occurences This event counts the number of L1D misses outstanding occurences.
>>
>> 	GOOD:
>> 	name:int_misc type:bitmask default:0x40
>>         	0x40 extra: rat_stall_cycles Cycles Resource Allocation Table (RAT) external stall is sent to Instruction Decode Queue (IDQ) for this thread.
>> 	        0x3 extra:cmask=1 recovery_cycles Number of cycles waiting to be recover after Nuke due to all other cases except JEClear.
>>         	0x3 extra:cmask=1,edge recovery_stalls_count Edge applied to recovery_cycles, thus counts occurrences.
>> 	=============
>>
>> 	The obvious difference between these two is that in the BAD case, one of the "extra" fields is a dummy,
>> 	but in the GOOD case, both "extra" fields have real extra values associated with them.  I don't know if
>> 	this difference is the cause of the problem, but it's certainly a good place to start looking.
>>
>> Thanks.
>>
>> -Maynard
>>
>>> -Andi
>>>
>>>
>>> ---------------------------------------------------------------------
>>> --------- This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> oprofile-list mailing list
>>> opr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>>>
>>
>>
>> ----------------------------------------------------------------------
>> -------- This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> oprofile-list mailing list
>> opr...@li...
>> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>>
> 
> 
>