Re: [PATCH] oprofile: Add support for Goldmont events

On 04/25/2016 05:45 PM, Andi Kleen wrote:
> I've sent a new patch addressing the typos.
> 
> On Mon, Apr 25, 2016 at 04:48:47PM -0400, William Cohen wrote:
>> Is there a matching patch for the testsuite to identify the Intel Goldmont processors, so the testsuite check that things are working?
> 
> There is not.

Thanks for the revised patch.

> 
>>> +#
>>> +# Note the minimum counts are not discovered experimentally and could be likely
>>> +# lowered in many cases without ill effect.
>>> +#
>>> +event:0x00 counters:cpuid um:cpu_clk_unhalted minimum:2000003 name:cpu_clk_unhalted :
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +event:0x03 counters:cpuid um:ld_blocks minimum:200003 name:ld_blocks :
>>> +event:0x05 counters:cpuid um:page_walks minimum:200003 name:page_walks :
>>> +event:0x0e counters:cpuid um:uops_issued minimum:200003 name:uops_issued_any :
>>> +event:0x13 counters:cpuid um:misalign_mem_ref minimum:200003 name:misalign_mem_ref :
>>> +event:0x2e counters:cpuid um:longest_lat_cache minimum:200003 name:longest_lat_cache :
>>> +event:0x30 counters:cpuid um:l2_reject_xq minimum:200003 name:l2_reject_xq_all :
>>> +event:0x31 counters:cpuid um:core_reject_l2q minimum:200003 name:core_reject_l2q_all :
>>
>> Table 17-24 includes 0x3c for CPU_CLK_UNHALTED. Is there a reason that this event is not included in this list?
> 
> 00 is equivalent for perf, points to the fixed counter or the generic
> counter.

okay.


> 
>>
>>> +	0x1 extra: hit Counts each cache line access to the Icache that are fulfilled (hit) by the Icache
>>> +	0x2 extra: misses Counts each cache line access to the Icache that are not fullfilled (miss) by the Icache
>>> +	0x3 extra: accesses Counts each cache line access to the Icache
>>> +name:inst_retired type:exclusive default:any
>>> +	0x0 extra: any Counts the number of instructions that retire execution. For instructions that consist of multiple uops, this event counts the retirement of the last uop of the instruction. The counter continues counting during hardware interrupts, traps, and inside interrupt handlers.  This event uses fixed counter 0.  You cannot collect a PEBs record for this event
>>> +	0x0 extra: any_p Counts the number of instructions that retire execution. For instructions that consist of multiple uops, this event counts the retirement of the last uop of the instruction. The event continues counting during hardware interrupts, traps, and inside interrupt handlers.  This is an architectural performance event.  This event uses a (_P)rogrammable general purpose performance counter. *This event is Precise Event capable:  The EventingRIP field in the PEBS record is precise to the address of the instruction which caused the event.  Note: Because PEBS records can be collected only on IA32_PMC0, only one event can use the PEBS facility at a time.
>>
>> Doesn't the any_p version need to be split into two unit masks? One for normal programmable counter use (any_p) and another for pebs use (any_pebs)?
> 
> Right one for PEBS, another without.

The updated patch does not have the any_pebs version for inst_retired.  Shouldn't there be a line for inst_retired umask like the following in there? 

0x0 extra:pebs any_pebs Counts the number of instructions that retire execution. For instructions that consist of multiple uops, this event counts the retirement of the last uop of the instruction. The event continues counting during hardware interrupts, traps, and inside interrupt handlers.  This is an architectural performance event.  This event uses a (_P)rogrammable general purpose performance counter. *This event is Precise Event capable:  The EventingRIP field in the PEBS record is precise to the address of the instruction which caused the event.  Note: Because PEBS records can be collected only on IA32_PMC0, only one event can use the PEBS facility at a time.
>>
> 
>>
>>> +name:uops_retired type:exclusive default:any
>>> +	0x0 extra: any Counts uops which retired
>>> +	0x0 extra:pebs any_pebs Counts uops which retired
>>> +	0x1 extra: ms Counts uops retired that are from the complex flows issued by the micro-sequencer (MS).  Counts both the uops from a micro-coded instruction, and the uops that might be generated from a micro-coded assist.
>>> +	0x1 extra:pebs ms_pebs Counts uops retired that are from the complex flows issued by the micro-sequencer (MS).  Counts both the uops from a micro-coded instruction, and the uops that might be generated from a micro-coded assist.
>>> +	0x8 extra: fpdiv Counts the number of floating point divide uops retired.
>>> +	0x8 extra:pebs fpdiv_pebs Counts the number of floating point divide uops retired.
>>> +	0x10 extra: idiv Counts the number of integer divide uops retired.
>>> +	0x10 extra:pebs idiv_pebs Counts the number of integer divide uops retired.
>>
>> Don't see fdiv (0x8) or idvi (0x10) listed in the table 19-24 for uops retired. Is something missing in the documentation? Or are those disabled because of some specfication update?
> 
> Not sure, but the my source files are generally newer.

Is the following the correct specification update for the goldmont processors?  I didn't see anything on the div/mul perf counters in there.

http://www.intel.com/content/www/us/en/processors/xeon/xeon-d-1500-specification-update.html

The lack of the div/mul events can be addressed later if needed. Won't worry about it on this patch.

> 
>>
>>> +	0x2 extra: recovery Counts the number of issue slots per core cycle that were not consumed by the backend because allocation is stalled waiting for a mispredicted jump to retire or other branch-like conditions (e.g. the event is relevant during certain microcode flows).   Counts all issue slots blocked while within this window including slots where uops were not available in the Instruction Queue.
>>> +name:hw_interrupts type:exclusive default:0x1
>>> +	0x1 extra: received Counts hardware interrupts received by the processor.
>>> +	0x4 extra: pending_and_masked Counts core cycles during which there are pending interrupts, but interrupts are masked (EFLAGS.IF = 0).
>>> +name:cycles_div_busy type:exclusive default:0x0
>>> +	0x0 extra: all Counts core cycles if either divide unit is busy.
>>> +	0x1 extra: idiv Counts core cycles the integer divide unit is busy.
>>> +	0x2 extra: fpdiv Counts core cycles the floating point divide unit is busy.
>>> +name:mem_uops_retired type:exclusive default:all
>>> +	0x83 extra: all Counts the number of memory uops retired that is either a loads or a store or both.
>>> +	0x81 extra: all_loads Counts the number of load uops retired
>>> +	0x81 extra:pebs all_loads_pebs Counts the number of load uops retired
>>> +	0x82 extra: all_stores Counts the number of store uops retired
>>> +	0x82 extra:pebs all_stores_pebs Counts the number of store uops retired
>>> +	0x83 extra:pebs all_pebs Counts the number of memory uops retired that is either a loads or a store or both.
>>
>> Any particular reason all_pebs and the all unit mask to group similar events together in the list?
> 
> A lot of events can be both PEBS and non PEBS sharing the same codes.
> In fact on Goldmont all events support that (although this is not
> expressed so far in oprofile)

I don't know how mechanically generated the umasks file is.  Most of the non-pebs and pebs versions are right next to each other in the file.  0x83 for mem_uops was one exception.  If the file is mechanically generated and the input file has them in that order, it might be simpler just to leave that particular one alone.  However, if it is a simple edit, swapping them would be easy and would provide more consistent output for ophelp.


-Will

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z