Re: [PATCH 09/12] perf_events: add hook to flush branch_stack on context switch (v2)

[Peter Zijlstra <peterz@infradead.org>]

On Thu, 2011-12-08 at 14:06 -0800, Stephane Eranian wrote:
> > That's not regardless of the TOS. If the TOS was a full u64 you wouldn't
> > need the TID (which would be good, since the hardware has no such
> > concept).
> >
> Maybe I missed the trick but I don't quite see how a 64-bit TOS would
> solve the TID
> problem. It's not about the wraparound issue, i.e., not like the
> sampling buffer indexes.
> Could you describe the trick again? 

LBR 0
.
.
.        <-- TOS % n
.
LBR n-1


So the LBR is an array of n entries which is written to in a cyclic
fashion. The Top-Of-Stack or TOS indicates the last written entry and we
can read n entries backwards from there.

Something like:

  tos = rdmsr(lbr_tos);
  for (i = 0; i < n; i++) {
	idx = (tos - i) % n;

	from = rdmsr(lbr_from + idx);
	to   = rdmsr(lbr_to   + idx);
  }

Now the hardware keeps (TOS % n) by limiting the bits in the counter (n
= 2^m etc..), if it wouldn't do that, we could sample the TOS on ctxsw
and modify the read to:

  tos = rdmsr(lbr_tos)
  for (i = 0; i < n && (tos - i) > ctxsw_tos; i++) {
	idx = (tos - i) % n;

	...
  }

This would ensure we never read back past the context-switch. But we
need the extra bits for this to work, since with the current limited
(TOS % n) bits we get into trouble as soon as the ctxsw was more than n
branches ago (which is something very likely).

[ With 16 bits we'd get into trouble when the ctxsw was 65536 branch
ago, which is still quite possible, at 32 bits we'd need 4G branches,
which is rather unlikely, with 64 bits the sun will have died or so.. ]

Also note we can make this extra condition conditional on the event
being a task event, so that the cpu events always consume all n entries.