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, [email protected]
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
