Messages in this thread | | | Subject | Re: [PATCH V3 13/23] perf/x86/intel/lbr: Factor out intel_pmu_store_lbr | From | "Liang, Kan" <> | Date | Mon, 6 Jul 2020 18:29:58 -0400 |
| |
On 7/3/2020 4:59 PM, Liang, Kan wrote: > > > On 7/3/2020 3:50 PM, Peter Zijlstra wrote: >> On Fri, Jul 03, 2020 at 05:49:19AM -0700, kan.liang@linux.intel.com >> wrote: >>> +static void intel_pmu_store_lbr(struct cpu_hw_events *cpuc, >>> + struct lbr_entry *entries) >>> +{ >>> + struct perf_branch_entry *e; >>> + struct lbr_entry *lbr; >>> + u64 from, to, info; >>> + int i; >>> + >>> + for (i = 0; i < x86_pmu.lbr_nr; i++) { >>> + lbr = entries ? &entries[i] : NULL; >>> + e = &cpuc->lbr_entries[i]; >>> + >>> + from = rdlbr_from(i, lbr); >>> + /* >>> + * Read LBR entries until invalid entry (0s) is detected. >>> + */ >>> + if (!from) >>> + break; >>> + >>> + to = rdlbr_to(i, lbr); >>> + info = rdlbr_info(i, lbr); >>> + >>> + e->from = from; >>> + e->to = to; >>> + e->mispred = !!(info & LBR_INFO_MISPRED); >>> + e->predicted = !(info & LBR_INFO_MISPRED); >>> + e->in_tx = !!(info & LBR_INFO_IN_TX); >>> + e->abort = !!(info & LBR_INFO_ABORT); >>> + e->cycles = info & LBR_INFO_CYCLES; >>> + e->type = 0; >>> + e->reserved = 0; >>> + } >>> + >>> + cpuc->lbr_stack.nr = i; >>> +} >> >> If I'm not mistaken, this correctly deals with LBR_FORMAT_INFO, so can't >> we also use the intel_pmu_arch_lbr_read() function for that case? >
There is another more severe issue which prevents sharing the read of Arch LBR with LBR_FORMAT_INFO. Sorry I missed it.
For the legacy LBR, the youngest branch is stored in TOS MSR. The next youngest is in (TOS - 1)...
For Arch LBR and LBR PEBS, the youngest branch is always in entry 0. The next youngest is in entry 1...
The growth of the legacy LBR is in a reversed order of Arch LBR and LBR PEBS. The legacy LBR also relies on TOS. I'm afraid we cannot use the intel_pmu_arch_lbr_read() function for LBR_FORMAT_INFO.
I think I will only send a patch to support NO_{CYCLES,FLAGS} for all LBR formats.
Thanks, Kan
| |