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 7ED40C433FE for ; Mon, 14 Mar 2022 04:06:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232502AbiCNEHF (ORCPT ); Mon, 14 Mar 2022 00:07:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229653AbiCNEHB (ORCPT ); Mon, 14 Mar 2022 00:07:01 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8091B3D4B2 for ; Sun, 13 Mar 2022 21:05:52 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id yy13so31134101ejb.2 for ; Sun, 13 Mar 2022 21:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=W/dRD6Rx16wawTOdNSffktT1rpicmUquQb1T9PyxOF4=; b=wb4nIzqtukyyCxvHVWoD7tabyArPdBqHSjIjuyto7e7a9YSwN9IPnaJS6LvCPN5bA7 uFS76gDRCoKKfZtaSYroVDWEftiENp2/lvZbu1sCL9/cEh2655ipupwGr2Dt+RHb3XHf Sf0ZNda2TL1IDjUb482FzWjmhvTpeXRKAe+8nS5JklYonDdqHClCDoKgk4E+CzqUaTyk gBSomrRcipit4Cgt4sB6LSTKJLHKyZHyHuUUTN4J5YrPP4des0NPftjEmdu/R0U1k6W3 a0SdQsc69w3G9fTN3hfxf7TYsZ3RY5FBp5KKhl9rZVVdsyXO6FycJMdWnl5HxB4CpCmZ VbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=W/dRD6Rx16wawTOdNSffktT1rpicmUquQb1T9PyxOF4=; b=J5MNxC5MiZmFTpFsoiJp6R+a0nn2/EX6NKz6yPl92CBKnTIkltrvVVeB0X7rQzlU0T 8b5mdVMeW7vjWgu3BKH43+foxr/pKqa26GBpp8hUpWa+K5dqm9ya4mvYEvL2v9l8q7m9 SVRGB7MEUsCurYBg1E6ghZvgD6zmDlOsmGUFqNTkYW3TwzwJw0baeFMS2nAGUpixhfaQ woRwgTFuFkpoJbE/i9RyvdMEonqL2cjHFm9Nk3Qe0Yx3orjjNsZizoqvGA861xxS6DfY 68Quk9y0LT/RvBWc/UGNa+Bic3b6paxCe3UO09XeaQzL5vozVzz7J043Ue13zcXNplW3 InAA== X-Gm-Message-State: AOAM533oLWCSu2p9Xb6MPrfWPA6KCsqWqv5AIvzFiNW5J93wDOY/HmeF BKZ8WBrJU4qCcMO7/5DCtt5lvw== X-Google-Smtp-Source: ABdhPJzXaoiudZPg8T4qpbCGaQkpUDn4+26ep+9/b6PevZn1vNxCt7WiyUq5ue2TCGUoaiZlsdEF1g== X-Received: by 2002:a17:907:3da4:b0:6da:9ec2:c3ff with SMTP id he36-20020a1709073da400b006da9ec2c3ffmr17082654ejc.90.1647230750924; Sun, 13 Mar 2022 21:05:50 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([104.245.96.34]) by smtp.gmail.com with ESMTPSA id kq26-20020a170906abda00b006da87077172sm6328735ejb.29.2022.03.13.21.05.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Mar 2022 21:05:50 -0700 (PDT) Date: Mon, 14 Mar 2022 12:05:42 +0800 From: Leo Yan To: Ali Saidi Cc: acme@kernel.org, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, benh@kernel.crashing.org, german.gomez@arm.com, james.clark@arm.com, john.garry@huawei.com, jolsa@redhat.com, kjain@linux.ibm.com, lihuafei1@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org, yao.jin@linux.intel.com Subject: Re: [PATCH v2 1/2] perf arm-spe: Use SPE data source for neoverse cores Message-ID: <20220314040542.GA163961@leoy-ThinkPad-X240s> References: <20220313114615.GA143848@leoy-ThinkPad-X240s> <20220313190619.18914-1-alisaidi@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220313190619.18914-1-alisaidi@amazon.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 13, 2022 at 07:06:19PM +0000, Ali Saidi wrote: [...] > > > > +static void arm_spe__synth_data_source_neoverse(const struct arm_spe_record *record, > > > > + union perf_mem_data_src *data_src) > > > > +{ > > > > + switch (record->source) { > > > > + case ARM_SPE_NV_L1D: > > > > + data_src->mem_lvl = PERF_MEM_LVL_HIT; > > > > > > I understand mem_lvl is deprecated but shouldn't we add the level bits here as well for backwards compat? > > > > Thanks for pointing out this. Yeah, I think German's suggestion is > > valid, the commit 6ae5fa61d27d ("perf/x86: Fix data source decoding > > for Skylake") introduces new field 'mem_lvl_num', but it also keeps > > backwards compatible for the field 'mem_lvl'. > > > I thought about that, but then I'm making some assumption about how to fit > this into the old LVL framework, which is perhaps OK (afaik there are no > Neoverse systems with more than 3 cache levels). What stopped me was that > perf_mem__lvl_scnprintf() does the wrong thing when both are set so I > assumed that setting both was not the right course of action. Thanks for pointing out this. I looked at perf_mem__lvl_scnprintf() and it prints both for fields 'mem_lvl' and 'mem_lvl_num'. Thus I can see the output result shows the duplicate info for memory access like "L1 or L1 hit", "L3 or L3 hit", etc. This would be a common issue crossing archs. Do I miss any other issues? > > > > + data_src->mem_lvl_num = PERF_MEM_LVLNUM_L1; > > > > + break; > > > > + case ARM_SPE_NV_L2: > > > > + data_src->mem_lvl = PERF_MEM_LVL_HIT; > > > > + data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2; > > > > + break; > > > > + case ARM_SPE_NV_PEER_CORE: > > > > + data_src->mem_lvl = PERF_MEM_LVL_HIT; > > > > + data_src->mem_snoop = PERF_MEM_SNOOP_HITM; > > > > + data_src->mem_lvl_num = PERF_MEM_LVLNUM_ANY_CACHE; > > > > For PEER_CORE data source, we don't know if it's coming from peer > > core's L1 cache or L2 cache, right? > > We don't. > > > If so, do you think if it's possible to retrieve more accurate info > > from the field "record->type"? > > No, we just don't know and it really doesn't matter. The main reason to > understand the source is to understand the penalty of data coming from > the source and that it's coming from a core should be sufficient. Okay, the question is Neoverse has three different data sources "ARM_SPE_NV_PEER_CORE", "ARM_SPE_NV_LCL_CLSTR" and "ARM_SPE_NV_PEER_CLSTR", but the patch only uses the same attribution for all of them. To be honest, I don't have precise understanding the definition for these three types, seems to me "ARM_SPE_NV_PEER_CORE" means to fetch data cache from peer core (like SMT things), "ARM_SPE_NV_LCL_CLSTR" means cache conherency within the same cluster with SCU, "ARM_SPE_NV_PEER_CLSTR" means the conherency happens with external bus (like CCI or CMN). So I'd like to suggest to consider to extend the level definitions so can allow us to express the data source for Arm arch precisely. It's important to understand current cache level definitions which is derived from x86 arch and think what's the good way to match and extend for Arm memory hierarchy. I will think a bit more for this, and if have any idea will share back. Thanks, Leo 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 7D929C433F5 for ; Mon, 14 Mar 2022 04:07:11 +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:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fVaH7DnPtd7P7GeNi3bIlK/QPsfeWptDIvlk9i+w5RQ=; b=awzsCjFyDPshkc yFk16smyUARoLhfhMnw+vFlmMzzLmiFt3VThnzMrz3hjoVrGKnR40bvhaLK8o3CYq49dnpjGPhCOI +xDwoRopgsawX/dntQR8xKouM+8UvGHjD+OrSq3P11fmla8jIG5Mwgv0AvrJLGH+ka8zKwISha78N I5xa66WlDGTqaa2nrxvSoJ+6NDrTv1pRU8Qi/rLp0YXgD1/iZgEDVzpvzUm2HaXeehVwe8S4/+ejz B6etB5qg1SAUNcPNfIct3U+4dupe48BGwF4Tl5zI1j2mBhTijsTnJybsNU3kxaRScmby/PgkjpkNg GkD4e9XzoL1+pUR5iZCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTby0-003mAS-7M; Mon, 14 Mar 2022 04:05:56 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTbxw-003m9q-KY for linux-arm-kernel@lists.infradead.org; Mon, 14 Mar 2022 04:05:54 +0000 Received: by mail-ej1-x634.google.com with SMTP id d10so31060951eje.10 for ; Sun, 13 Mar 2022 21:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=W/dRD6Rx16wawTOdNSffktT1rpicmUquQb1T9PyxOF4=; b=wb4nIzqtukyyCxvHVWoD7tabyArPdBqHSjIjuyto7e7a9YSwN9IPnaJS6LvCPN5bA7 uFS76gDRCoKKfZtaSYroVDWEftiENp2/lvZbu1sCL9/cEh2655ipupwGr2Dt+RHb3XHf Sf0ZNda2TL1IDjUb482FzWjmhvTpeXRKAe+8nS5JklYonDdqHClCDoKgk4E+CzqUaTyk gBSomrRcipit4Cgt4sB6LSTKJLHKyZHyHuUUTN4J5YrPP4des0NPftjEmdu/R0U1k6W3 a0SdQsc69w3G9fTN3hfxf7TYsZ3RY5FBp5KKhl9rZVVdsyXO6FycJMdWnl5HxB4CpCmZ VbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=W/dRD6Rx16wawTOdNSffktT1rpicmUquQb1T9PyxOF4=; b=Jni5jjdte4pW++6OmCC4cZYZHPJFJPRo3ySZLsWw3yHNPQR/wcYo6Jajo6urhn1+KP B/hTavYU8sRWxeGJATnGhlHGP+v3rH5Fnq9DfC3nGnBuMZtQmxxeIfrGSjaMObeM8e/F CALE1n2XmR5igcsiFXXjV18fzXUs4SXfboa5pUUf3To59t0X5BdASdvT5gygSmKgkc2a t4bO+J04lUVKkybw0I60Qs9CN4VJZKwTF4evfNxYDQ+Bkg8x6uQlzW6PxKrRrzszt8+p loAjfu8zoKhJgwvW+Lz+YRTCrb4FKHBAaaQLgnM4Z3GLKpVUedvn3HQ28Mlr1w51p3v5 i7sg== X-Gm-Message-State: AOAM533GxjCZT7a2q0B3mPomrkt9JugzKw7297vQ9awSGEtkNnBbSRyL 3Yni/Lb1eUY05ZF11zB8gbpnFQ== X-Google-Smtp-Source: ABdhPJzXaoiudZPg8T4qpbCGaQkpUDn4+26ep+9/b6PevZn1vNxCt7WiyUq5ue2TCGUoaiZlsdEF1g== X-Received: by 2002:a17:907:3da4:b0:6da:9ec2:c3ff with SMTP id he36-20020a1709073da400b006da9ec2c3ffmr17082654ejc.90.1647230750924; Sun, 13 Mar 2022 21:05:50 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([104.245.96.34]) by smtp.gmail.com with ESMTPSA id kq26-20020a170906abda00b006da87077172sm6328735ejb.29.2022.03.13.21.05.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Mar 2022 21:05:50 -0700 (PDT) Date: Mon, 14 Mar 2022 12:05:42 +0800 From: Leo Yan To: Ali Saidi Cc: acme@kernel.org, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, benh@kernel.crashing.org, german.gomez@arm.com, james.clark@arm.com, john.garry@huawei.com, jolsa@redhat.com, kjain@linux.ibm.com, lihuafei1@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org, yao.jin@linux.intel.com Subject: Re: [PATCH v2 1/2] perf arm-spe: Use SPE data source for neoverse cores Message-ID: <20220314040542.GA163961@leoy-ThinkPad-X240s> References: <20220313114615.GA143848@leoy-ThinkPad-X240s> <20220313190619.18914-1-alisaidi@amazon.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220313190619.18914-1-alisaidi@amazon.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220313_210552_753448_11CD0070 X-CRM114-Status: GOOD ( 30.89 ) 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 Sun, Mar 13, 2022 at 07:06:19PM +0000, Ali Saidi wrote: [...] > > > > +static void arm_spe__synth_data_source_neoverse(const struct arm_spe_record *record, > > > > + union perf_mem_data_src *data_src) > > > > +{ > > > > + switch (record->source) { > > > > + case ARM_SPE_NV_L1D: > > > > + data_src->mem_lvl = PERF_MEM_LVL_HIT; > > > > > > I understand mem_lvl is deprecated but shouldn't we add the level bits here as well for backwards compat? > > > > Thanks for pointing out this. Yeah, I think German's suggestion is > > valid, the commit 6ae5fa61d27d ("perf/x86: Fix data source decoding > > for Skylake") introduces new field 'mem_lvl_num', but it also keeps > > backwards compatible for the field 'mem_lvl'. > > > I thought about that, but then I'm making some assumption about how to fit > this into the old LVL framework, which is perhaps OK (afaik there are no > Neoverse systems with more than 3 cache levels). What stopped me was that > perf_mem__lvl_scnprintf() does the wrong thing when both are set so I > assumed that setting both was not the right course of action. Thanks for pointing out this. I looked at perf_mem__lvl_scnprintf() and it prints both for fields 'mem_lvl' and 'mem_lvl_num'. Thus I can see the output result shows the duplicate info for memory access like "L1 or L1 hit", "L3 or L3 hit", etc. This would be a common issue crossing archs. Do I miss any other issues? > > > > + data_src->mem_lvl_num = PERF_MEM_LVLNUM_L1; > > > > + break; > > > > + case ARM_SPE_NV_L2: > > > > + data_src->mem_lvl = PERF_MEM_LVL_HIT; > > > > + data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2; > > > > + break; > > > > + case ARM_SPE_NV_PEER_CORE: > > > > + data_src->mem_lvl = PERF_MEM_LVL_HIT; > > > > + data_src->mem_snoop = PERF_MEM_SNOOP_HITM; > > > > + data_src->mem_lvl_num = PERF_MEM_LVLNUM_ANY_CACHE; > > > > For PEER_CORE data source, we don't know if it's coming from peer > > core's L1 cache or L2 cache, right? > > We don't. > > > If so, do you think if it's possible to retrieve more accurate info > > from the field "record->type"? > > No, we just don't know and it really doesn't matter. The main reason to > understand the source is to understand the penalty of data coming from > the source and that it's coming from a core should be sufficient. Okay, the question is Neoverse has three different data sources "ARM_SPE_NV_PEER_CORE", "ARM_SPE_NV_LCL_CLSTR" and "ARM_SPE_NV_PEER_CLSTR", but the patch only uses the same attribution for all of them. To be honest, I don't have precise understanding the definition for these three types, seems to me "ARM_SPE_NV_PEER_CORE" means to fetch data cache from peer core (like SMT things), "ARM_SPE_NV_LCL_CLSTR" means cache conherency within the same cluster with SCU, "ARM_SPE_NV_PEER_CLSTR" means the conherency happens with external bus (like CCI or CMN). So I'd like to suggest to consider to extend the level definitions so can allow us to express the data source for Arm arch precisely. It's important to understand current cache level definitions which is derived from x86 arch and think what's the good way to match and extend for Arm memory hierarchy. I will think a bit more for this, and if have any idea will share back. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel