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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B45B8C433EF for ; Tue, 15 Mar 2022 13:06:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242175AbiCONIG (ORCPT ); Tue, 15 Mar 2022 09:08:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348565AbiCONIB (ORCPT ); Tue, 15 Mar 2022 09:08:01 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9615F50E13; Tue, 15 Mar 2022 06:06:49 -0700 (PDT) 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 4FD031474; Tue, 15 Mar 2022 06:06:49 -0700 (PDT) Received: from [10.57.42.204] (unknown [10.57.42.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1F2313F66F; Tue, 15 Mar 2022 06:06:46 -0700 (PDT) Message-ID: <0df5c352-1f0d-55f8-5d7f-e28ba33d623b@arm.com> Date: Tue, 15 Mar 2022 13:06:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH V4 03/10] perf: Extend branch type classification Content-Language: en-GB To: Peter Zijlstra , Anshuman Khandual Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, acme@kernel.org, Suzuki Poulose , James Clark , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org References: <20220315053516.431515-1-anshuman.khandual@arm.com> <20220315053516.431515-4-anshuman.khandual@arm.com> <20220315112232.GF8939@worktop.programming.kicks-ass.net> From: Robin Murphy In-Reply-To: <20220315112232.GF8939@worktop.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-03-15 11:22, Peter Zijlstra wrote: > On Tue, Mar 15, 2022 at 11:05:09AM +0530, Anshuman Khandual wrote: >> branch_entry.type now has ran out of space to accommodate more branch types >> classification. This will prevent perf branch stack implementation on arm64 >> (via BRBE) to capture all available branch types. Extending this bit field >> i.e branch_entry.type [4 bits] is not an option as it will break user space >> ABI both for little and big endian perf tools. >> >> Extend branch classification with a new field branch_entry.new_type via a >> new branch type PERF_BR_EXTEND_ABI in branch_entry.type. Perf tools which >> could decode PERF_BR_EXTEND_ABI, will then parse branch_entry.new_type as >> well. >> >> branch_entry.new_type is a 4 bit field which can hold upto 16 branch types. >> The first three branch types will hold various generic page faults followed >> by five architecture specific branch types, which can be overridden by the >> platform for specific use cases. These architecture specific branch types >> gets overridden on arm64 platform for BRBE implementation. > >> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h >> index 26d8f0b5ac0d..d29280adc3c4 100644 >> --- a/include/uapi/linux/perf_event.h >> +++ b/include/uapi/linux/perf_event.h >> @@ -255,9 +255,22 @@ enum { >> PERF_BR_IRQ = 12, /* irq */ >> PERF_BR_SERROR = 13, /* system error */ >> PERF_BR_NO_TX = 14, /* not in transaction */ >> + PERF_BR_EXTEND_ABI = 15, /* extend ABI */ >> PERF_BR_MAX, >> }; > > >> #define PERF_SAMPLE_BRANCH_PLM_ALL \ >> (PERF_SAMPLE_BRANCH_USER|\ >> PERF_SAMPLE_BRANCH_KERNEL|\ >> @@ -1372,7 +1385,8 @@ struct perf_branch_entry { >> abort:1, /* transaction abort */ >> cycles:16, /* cycle count to last branch */ >> type:4, /* branch type */ >> - reserved:40; >> + new_type:4, /* additional branch type */ >> + reserved:36; >> }; > > Hurmpf... this will effectively give us 5 bits of space for the cost of > 8, that seems... unfortunate. > > Would something like: > > type:4, > ext_type:4, > reserved:36; > > and have all software do: > > type = pbe->type | (pbe->ext_type << 4); > > Then old software will only know about the old types. New software on > old kernels will add 4 0's, which is harmless, while new software on new > kernels will get 8 bytes of type. > > Would that work? Depends how bad the effects of aliasing in existing software would be, I guess - e.g. new kernel outputs type 0x23 which software then interprets as 0x3 since it doesn't know about the extended bits. I'm guessing that's more likely "confusing to the user" than "catastrophically fatal", but it might still matter. If software had an explicit opt-in to receiving extended types when requesting branch sampling in the first place we could avoid that worry, but then we'd need some additional complexity to sanitise records depending on that option :/ Robin. 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 6EEA0C433EF for ; Tue, 15 Mar 2022 13:08:03 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=CnRgbzuoEXGqcK6S55uImpaAoe3oSHAI55B/VWakaFY=; b=BW7RjQN+0DWS3A US1+OT0KcjMOaw2oR/p8g/tiTvR06zIHj3BhdR6wPuxEayvx2rSA0OtZDP43cXHxgHdCCxfnJrFLS EwdYRye6y1EwCqa0KqYHmgFc2rzK8CeH7IWWwIa081Jf/b+0AIzSk2Wv7lz8Kdf3nbunwkESEeF67 Q9PbZQtWz7ScmtVDXUFbPUF0Hq8iAwaYHKSABEQmmmiW8IxckcCjOR7ml3spV+5UjmY9AXoIbSdJM EjMz9O8bOqArtmkMRLX4/Ztu0l81xZ0lTDpcT0GsB3dHfVao/sepFZsJu1hTmwSTo9RzHFmGtQD5d aF+HZVm0vrrgAhv+RxJw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nU6t7-00974U-HC; Tue, 15 Mar 2022 13:06:57 +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 1nU6t2-00972o-Lo for linux-arm-kernel@lists.infradead.org; Tue, 15 Mar 2022 13:06:54 +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 4FD031474; Tue, 15 Mar 2022 06:06:49 -0700 (PDT) Received: from [10.57.42.204] (unknown [10.57.42.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1F2313F66F; Tue, 15 Mar 2022 06:06:46 -0700 (PDT) Message-ID: <0df5c352-1f0d-55f8-5d7f-e28ba33d623b@arm.com> Date: Tue, 15 Mar 2022 13:06:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH V4 03/10] perf: Extend branch type classification Content-Language: en-GB To: Peter Zijlstra , Anshuman Khandual Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, acme@kernel.org, Suzuki Poulose , James Clark , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org References: <20220315053516.431515-1-anshuman.khandual@arm.com> <20220315053516.431515-4-anshuman.khandual@arm.com> <20220315112232.GF8939@worktop.programming.kicks-ass.net> From: Robin Murphy In-Reply-To: <20220315112232.GF8939@worktop.programming.kicks-ass.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220315_060652_872292_6662721B X-CRM114-Status: GOOD ( 23.56 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-03-15 11:22, Peter Zijlstra wrote: > On Tue, Mar 15, 2022 at 11:05:09AM +0530, Anshuman Khandual wrote: >> branch_entry.type now has ran out of space to accommodate more branch types >> classification. This will prevent perf branch stack implementation on arm64 >> (via BRBE) to capture all available branch types. Extending this bit field >> i.e branch_entry.type [4 bits] is not an option as it will break user space >> ABI both for little and big endian perf tools. >> >> Extend branch classification with a new field branch_entry.new_type via a >> new branch type PERF_BR_EXTEND_ABI in branch_entry.type. Perf tools which >> could decode PERF_BR_EXTEND_ABI, will then parse branch_entry.new_type as >> well. >> >> branch_entry.new_type is a 4 bit field which can hold upto 16 branch types. >> The first three branch types will hold various generic page faults followed >> by five architecture specific branch types, which can be overridden by the >> platform for specific use cases. These architecture specific branch types >> gets overridden on arm64 platform for BRBE implementation. > >> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h >> index 26d8f0b5ac0d..d29280adc3c4 100644 >> --- a/include/uapi/linux/perf_event.h >> +++ b/include/uapi/linux/perf_event.h >> @@ -255,9 +255,22 @@ enum { >> PERF_BR_IRQ = 12, /* irq */ >> PERF_BR_SERROR = 13, /* system error */ >> PERF_BR_NO_TX = 14, /* not in transaction */ >> + PERF_BR_EXTEND_ABI = 15, /* extend ABI */ >> PERF_BR_MAX, >> }; > > >> #define PERF_SAMPLE_BRANCH_PLM_ALL \ >> (PERF_SAMPLE_BRANCH_USER|\ >> PERF_SAMPLE_BRANCH_KERNEL|\ >> @@ -1372,7 +1385,8 @@ struct perf_branch_entry { >> abort:1, /* transaction abort */ >> cycles:16, /* cycle count to last branch */ >> type:4, /* branch type */ >> - reserved:40; >> + new_type:4, /* additional branch type */ >> + reserved:36; >> }; > > Hurmpf... this will effectively give us 5 bits of space for the cost of > 8, that seems... unfortunate. > > Would something like: > > type:4, > ext_type:4, > reserved:36; > > and have all software do: > > type = pbe->type | (pbe->ext_type << 4); > > Then old software will only know about the old types. New software on > old kernels will add 4 0's, which is harmless, while new software on new > kernels will get 8 bytes of type. > > Would that work? Depends how bad the effects of aliasing in existing software would be, I guess - e.g. new kernel outputs type 0x23 which software then interprets as 0x3 since it doesn't know about the extended bits. I'm guessing that's more likely "confusing to the user" than "catastrophically fatal", but it might still matter. If software had an explicit opt-in to receiving extended types when requesting branch sampling in the first place we could avoid that worry, but then we'd need some additional complexity to sanitise records depending on that option :/ Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel