Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1430737 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH 1/1] perf/x86/intel: Add extended event constraints for  Knights Landing "Odzioba, Lukasz" <lukasz.odzioba@intel.com> - 2016-06-24 17:00 +0200
    Re: [PATCH 1/1] perf/x86/intel: Add extended event constraints for  Knights Landing Stephane Eranian <eranian@google.com> - 2016-06-24 19:10 +0200

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

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

[toc] | [next] | [standalone]

#1430817

Hi,

On Fri, Jun 24, 2016 at 7:54 AM, Odzioba, Lukasz
<lukasz.odzioba@intel.com> wrote:
> 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.
>
What happens if I do in one run:
   2- cpu/event=0xb7,umask=0x1,offcore_rsp=0x100/u,cpu/event=0xb7,umask=0x2,offcore_rsp=0x100/k
   3- cpu/event=0xb7,umask=0x1,offcore_rsp=1ull<<38/,cpu/event=0xb7,umask=0x1,offcore_rsp=0x1/
   4- cpu/event=0xb7,umask=0x1,offcore_rsp=1ull<<38/,cpu/event=0xb7,umask=0x1,offcore_rsp=1ull<<38|1/

You get the shared constraints BEFORE the static constraints. So if
you've gone thru intel_alt_er() , then you should still be fine. In
case of counter conflict during scheduling the shared regs are free in
put_event_constraints(). So it should be fine there too.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web