Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Jin, Yao]

On 7/11/2017 10:28 AM, Michael Ellerman wrote:
> "Jin, Yao" <yao.jin@xxxxxxxxxxxxxxx> writes:
>
> > On 7/10/2017 9:46 PM, Peter Zijlstra wrote:
> > > On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:
> > >
> > > > > PERF_BR_INT is triggered by instruction "int" .
> > > > > PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
> > > > > transition).
> > > > So your "PERF_BR_INT" is a system call?
> > > The "INT" thing has indeed been used as system call mechanism (typically
> > > INT 80). But these days we have special purpose syscall instructions.
> > >
> > > It could maybe be compared to the PPC "Unconditional TRAP with
> > > immediate" where you use the immediate value as an index into a handler
> > > vector.
> > >
> > > > And PERF_BR_IRQ is not an interrupt request (as its name suggests),
> > > > not what we call an "external interrupt" either; instead it is every
> > > > interrupt that is not a system call?
> > > It is actual interrupts, but also faults, traps and all the other
> > > exceptions not caused by "INT" I think.
> > Yes. It's interrupt, traps, faults. If from is in the user space and to
> > is in the kernel, it indicates the ring3 -> ring0 transition.
> >
> > If the from instruction is not syscall or other ring transition
> > instruction, it should be interrupt, traps and faults. That's how we get
> > the PERF_BR_IRQ on x86.
> >
> > Anyway, maybe we just use a minimum but the most common set of branch
> > types now, it could be a good start and acceptable on all architectures.
> >
> > PERF_BR_COND        = 1,    /* conditional */
> > PERF_BR_UNCOND        = 2,    /* unconditional */
> > PERF_BR_IND        = 3,    /* indirect */
> > PERF_BR_CALL        = 4,    /* call */
> > PERF_BR_IND_CALL    = 5,    /* indirect call */
> > PERF_BR_RET        = 6,    /* return */
> That would be fine by me, if you're sick of talking about it and just
> want to get it merged :)
:)
> I think you could expand it a bit, this list would cover the vast bulk
> of branch types for us:
>
>    PERF_BR_COND		/* Conditional */
>    PERF_BR_UNCOND	/* Unconditional */
>    PERF_BR_IND		/* Indirect */
>    PERF_BR_CALL		/* Function call */
>    PERF_BR_IND_CALL	/* Indirect function call */
>    PERF_BR_RET		/* Function return */
>    PERF_BR_SYSCALL	/* Syscall */
>    PERF_BR_SYSRET	/* Syscall return */
>    PERF_BR_COND_CALL	/* Conditional function call */
>    PERF_BR_COND_RET	/* Conditional function return */
>
> cheers

OK, accept! Use 4 bits for above branch types and we can reserve 5 for 
potential future types.

Thanks
Jin Yao