RE: [PATCH 1/1] perf/x86/intel: Add extended event constraints for Knights Landing

[Odzioba, Lukasz]

On Tuesday, June 21, 2016 11:38 AM, Peter Zijlstra wrote:
> Yes, that is the intent, but how is this achieved? I'm not sure I see
> how the patch ensure this.

If you are confused, then it is likely that I did something wrong here.
Let me explain myself.

We already have a mechanism to create static constraints which limit events
to given PMCs via event code filtering. Such constraints are later obeyed by event 
scheduler to assure that. Scheduler bases its decisions on idxmsk to place events
on the right PMC.

We can think of OFFCORE_RESPONSE/config1 values as an extension
of event code making it 128bit long (code+extended code).

Emask is extended code logically ANDed with extended code mask (analogy to 
c->cmask and c->code), we could add separate values here, but I didn't see a real use
for it right now.

Event code is used only in x86_get_event_constraints, so we have to extend event 
code matching check there to use config1 against our new emask.
If constraint code matches event code and constraint has non empty extended
code we check it against config1, if config1 uses one of the bits defined in emask
we return constraint as if would be normal 64bit-code constraint, scheduler will take
care of the rest.

> Also, intel_get_event_constraints() has a path where it copies the
> constraint, should it not also copy the new field?

Since event code is not used anywhere except x86_get_event_constraints, 
so extended code is also not needed there.

To verify that it works as I expect I added printk's to x86_assign_hw_event
to see selected PMC.

Thanks,
Lukas