Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1430817
| From | Stephane Eranian <eranian@google.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/1] perf/x86/intel: Add extended event constraints for Knights Landing |
| Date | 2016-06-24 19:10 +0200 |
| Message-ID | <rNCMa-2vW-5@gated-at.bofh.it> (permalink) |
| References | <rHCYx-3wB-1@gated-at.bofh.it> <rHFto-4Z9-45@gated-at.bofh.it> <rM4Mx-73V-1@gated-at.bofh.it> <rMrg7-4Cx-67@gated-at.bofh.it> <rNAKl-UD-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
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
csiph-web