From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F39CEC433F5 for ; Thu, 24 Feb 2022 07:11:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=l4M3amQpRqM3aXMLmlK7jSK3beU1bnYBxPwLEZI9jsM=; b=WfjTox+M8vAMdZIlD/VkDwoH9o jpxGXOdXdwFwM+GyyuEmp+C2ddPTZhrlCem8S5pMiCX9WyqcJzAk4I7jYsjBwS5TQxo9x+uqX8mMa ro4Ilw+YuZpoG6Afs5TW0zGhpaoAlQ6e6vppEv/h0b09d9tzeqPdTJJMDJvLuUKCaPXDYopzp5SVU WdxIscmgWNm1uHqrrgg1xIz77Y23StrlTfZBcDo0OhqX8LfNVJD3//Sl0brqiygaG5CP8meb/CC8h Gr1DQtnUcGkUXMNQ7Tsg1vFG5sGFA+6kueeW+E+NSvCCnR1vaPBaechG22uXXIgL3U58eKGSRS1gV aEorGe0g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nN8Ga-00H6Cq-6m; Thu, 24 Feb 2022 07:10:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nN8GW-00H6Bd-8o for linux-arm-kernel@lists.infradead.org; Thu, 24 Feb 2022 07:10:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 99A7D106F; Wed, 23 Feb 2022 23:10:12 -0800 (PST) Received: from [10.163.48.178] (unknown [10.163.48.178]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 38D7F3F70D; Wed, 23 Feb 2022 23:10:08 -0800 (PST) Subject: Re: [PATCH 1/2] perf: Add more generic branch types From: Anshuman Khandual To: Mark Rutland Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, robh@kernel.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Will Deacon References: <1643348653-24367-1-git-send-email-anshuman.khandual@arm.com> <1643348653-24367-2-git-send-email-anshuman.khandual@arm.com> Message-ID: <25a36640-3061-4c98-4da0-ceb039439f42@arm.com> Date: Thu, 24 Feb 2022 12:40:11 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220223_231016_443137_A506A295 X-CRM114-Status: GOOD ( 18.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/24/22 11:21 AM, Anshuman Khandual wrote: > > > On 2/2/22 5:28 PM, Mark Rutland wrote: >> Hi Anshuman, >> >> On Fri, Jan 28, 2022 at 11:14:12AM +0530, Anshuman Khandual wrote: >>> This expands generic branch type classification by adding some more entries >>> , that can still be represented with the existing 4 bit 'type' field. While >>> here this also updates the x86 implementation with these new branch types. >> It looks like there's some whitespace damage here. >> >> >From a quick scan of the below, I think the "exception return" and "IRQ >> exception" types are somewhat generic, and could be added now (aside from any >> bikeshedding over names), but: > > Hi Mark, > > I have sent a patch adding just PERF_BR_ERET and PERF_BR_IRQ which are generic > enough to be included now. The 'type' field still got 3 more places for future > use. Hence we should try and include two more branch types, before adding the The two additional generic branch types could be - PERF_BR_SERROR (possible arm64 equivalent for x86 MCE) - PERF_BR_NO_TX (only missing TX related branch type in perf_branch_entry) perf_branch_entry.[in_tx | abort] are already available. Also PERF_BR_NO_TX could be used right away on x86 platform, via X86_BR_NO_TX. > last entry for ABI expansion (e.g PERF_BR_EXTENDED). PERF_BR_EXTENDED could help expand into another 4 bits 'new_type' field following the existing 4 bits 'type' field. Does this sound feasible ? enum { PERF_BR_UNKNOWN = 0, /* unknown */ PERF_BR_COND = 1, /* conditional */ PERF_BR_UNCOND = 2, /* unconditional */ PERF_BR_IND = 3, /* indirect */ PERF_BR_CALL = 4, /* function call */ PERF_BR_IND_CALL = 5, /* indirect function call */ PERF_BR_RET = 6, /* function return */ PERF_BR_SYSCALL = 7, /* syscall */ PERF_BR_SYSRET = 8, /* syscall return */ PERF_BR_COND_CALL = 9, /* conditional function call */ PERF_BR_COND_RET = 10, /* conditional function return */ PERF_BR_ERET = 11, /* exception return */ PERF_BR_IRQ = 12, /* irq */ PERF_BR_SERROR = 13, /* System error */ PERF_BR_NO_TX = 14, /* No transaction */ PERF_BR_EXTEND_ABI = 15 /* Extended ABI */ PERF_BR_MAX, }; enum { PERF_BR_NEW_FAULT_ALGN = 0, /* Alignment fault */ PERF_BR_NEW_FAULT_DATA = 1, /* Data fault */ PERF_BR_NEW_FAULT_INST = 2, /* Inst fault */ PERF_BR_NEW_ARCH_1 = 3, /* Architecture specific */ PERF_BR_NEW_ARCH_2 = 4, /* Architecture specific */ PERF_BR_NEW_ARCH_3 = 5, /* Architecture specific */ PERF_BR_NEW_ARCH_4 = 6, /* Architecture specific */ PERF_BR_NEW_ARCH_5 = 7, /* Architecture specific */ PERF_BR_NEW_MAX, }; #ifdef CONFIG_ARM64 #define PERF_BR_FIQ PERF_BR_NEW_ARCH_1 #define PERF_BR_DEBUG_HALT PERF_BR_NEW_ARCH_2 #define PERF_BR_DEBUG_EXIT PERF_BR_NEW_ARCH_3 #define PERF_BR_DEBUG_INST PERF_BR_NEW_ARCH_4 #define PERF_BR_DEBUG_DATA PERF_BR_NEW_ARCH_5 #endif User space perf tool will look into perf_branch_entry.new_type, only when (perf_branch_entry.type == PERF_BR_EXTEND_ABI). Older perf tool on a newer kernel will be safe via old PERF_BR_MAX, and will ignore [PERF_BR_ERET - PERF_BR_EXTEND_ABI] values possibly with an warning. - Anshuman _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel