Re: [patch] perf_events: even more wrong events for AMD fam10h

[Robert Richter]

On 27.06.11 07:22:21, Peter Zijlstra wrote:
> On Tue, 2011-06-07 at 17:07 -0400, Vince Weaver wrote:
> > Here are two more problems I found with the superlative "generalized" 
> > events on AMD fam10h.
> > 
> > The "l1-dcache-loads" event measures loads *and* stores.
> >     This might be as close as you can get on AMD, but it's still wrong
> >       as it's not what Intel measures.  
> >     My patch removes it.  Better might be to add a proper
> >     "l1-dcache-access" event.
> 
> The question to ask is, does it still have a strong correlation?

Vince,

do you think it is worth to introduce l1-dcache-access?

> 
> > The "l1-dcache-load-miss" event is an invalid event. (0x141).
> >     From what I can tell that event (DATA_CACHE_MISSES) does not
> >     take a mask.  It should be 0x41.  And it's actually measuring
> >     all misses, not just load misses, see above.
> 
> See commit 83112e688f5f05dea1e63787db9a6c16b2887a1d. Also same as above.

It is still event 0x41, but bit 0 of the unit mask is set now for
family 15h.

> 
> > The "l1-dcache-stores" event does not work.  See the
> >      ./validation/l1-dcache-stores test found in 
> >      http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html
> >    So remove it until we figure out why.
> > 
> 
> Robert?

Will look at this.

> 
> > Also, is the value for "no such event" 0 or -1?  The perf_event_amd.c
> > file seems to use them interchangably from what I can tell.
> 
> 	val = hw_cache_event_ids[cache_type][cache_op][cache_result];
> 
> 	if (val == 0)
> 		return -ENOENT;
> 
> 	if (val == -1)
> 		return -EINVAL;
> 
> 
> But yeah, somewhat inconsistent. Robert, Andre, could you guys go over
> the AMD events some time?
> 

We will review all predefined events.

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/