From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756161AbdGLKqV convert rfc822-to-8bit (ORCPT ); Wed, 12 Jul 2017 06:46:21 -0400 Received: from ozlabs.org ([103.22.144.67]:36679 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbdGLKqU (ORCPT ); Wed, 12 Jul 2017 06:46:20 -0400 From: Michael Ellerman To: Jin Yao , acme@kernel.org, jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com Cc: Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com, Jin Yao Subject: Re: [PATCH v7 1/7] perf/core: Define the common branch type classification In-Reply-To: <1499785263-17383-2-git-send-email-yao.jin@linux.intel.com> References: <1499785263-17383-1-git-send-email-yao.jin@linux.intel.com> <1499785263-17383-2-git-send-email-yao.jin@linux.intel.com> User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Wed, 12 Jul 2017 20:46:18 +1000 Message-ID: <87iniykk5h.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jin Yao writes: > It is often useful to know the branch types while analyzing branch > data. For example, a call is very different from a conditional branch. > > Currently we have to look it up in binary while the binary may later > not be available and even the binary is available but user has to take > some time. It is very useful for user to check it directly in perf > report. > > Perf already has support for disassembling the branch instruction > to get the x86 branch type. > > To keep consistent on kernel and userspace and make the classification > more common, the patch adds the common branch type classification > in perf_event.h. > > The patch only defines a minimum but most common set of branch types. > > PERF_BR_NONE : unknown > 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 This series looks good to me, I agree with Peter that UNKNOWN would be better than NONE. I'll add it to my list of things we need to implement on powerpc. cheers