Messages in this thread | | | Date | Wed, 27 Jan 2021 20:16:16 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 03/12] perf/x86/intel: Add perf core PMU support for Sapphire Rapids |
| |
On Tue, Jan 26, 2021 at 10:44:17AM -0500, Liang, Kan wrote: > > > On 1/26/2021 9:44 AM, Peter Zijlstra wrote: > > On Tue, Jan 19, 2021 at 12:38:22PM -0800, kan.liang@linux.intel.com wrote: > > > @@ -3671,6 +3853,31 @@ static int intel_pmu_hw_config(struct perf_event *event) > > > } > > > } > > > + /* > > > + * To retrieve complete Memory Info of the load latency event, an > > > + * auxiliary event has to be enabled simultaneously. Add a check for > > > + * the load latency event. > > > + * > > > + * In a group, the auxiliary event must be in front of the load latency > > > + * event. The rule is to simplify the implementation of the check. > > > + * That's because perf cannot have a complete group at the moment. > > > + */ > > > + if (x86_pmu.flags & PMU_FL_MEM_LOADS_AUX && > > > + (event->attr.sample_type & PERF_SAMPLE_DATA_SRC) && > > > + is_mem_loads_event(event)) { > > > + struct perf_event *leader = event->group_leader; > > > + struct perf_event *sibling = NULL; > > > + > > > + if (!is_mem_loads_aux_event(leader)) { > > > + for_each_sibling_event(sibling, leader) { > > > + if (is_mem_loads_aux_event(sibling)) > > > + break; > > > + } > > > + if (list_entry_is_head(sibling, &leader->sibling_list, sibling_list)) > > > + return -ENODATA; > > > + } > > > + } > > > + > > > if (!(event->attr.config & ARCH_PERFMON_EVENTSEL_ANY)) > > > return 0; > > > > I have vague memories of this getting mentioned in a call at some point. > > Pretend I don't know anything and tell me more. > > > > Adding the auxiliary event is for the new data source fields, data block & > address block. If perf only samples the load latency event, the value of the > data block & address block fields in a sample is not correct. To get the > correct value, we have to sample both the auxiliary event and the load > latency together on SPR. So I add the check in the kernel. I also modify the > perf mem in the perf tool accordingly.
This is an active work around for a chip defect right? Something we're normally have an errata for. Can we call it that?
| |