[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87shi37lmp.fsf@concordia.ellerman.id.au>
Date: Tue, 11 Jul 2017 12:28:14 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: "Jin\, Yao" <yao.jin@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Segher Boessenkool <segher@...nel.crashing.org>
Cc: acme@...nel.org, jolsa@...nel.org, mingo@...hat.com,
alexander.shishkin@...ux.intel.com, kan.liang@...el.com,
ak@...ux.intel.com, linuxppc-dev@...ts.ozlabs.org,
Linux-kernel@...r.kernel.org, yao.jin@...el.com
Subject: Re: [PATCH v6 1/7] perf/core: Define the common branch type classification
"Jin, Yao" <yao.jin@...ux.intel.com> 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
Powered by blists - more mailing lists