Hi, On Fri, Jun 24, 2016 at 7:54 AM, Odzioba, Lukasz <lukasz.odzi...@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.
