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 D3095C433EF for ; Sat, 26 Mar 2022 13:30:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233060AbiCZNcP (ORCPT ); Sat, 26 Mar 2022 09:32:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229667AbiCZNcN (ORCPT ); Sat, 26 Mar 2022 09:32:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 591D2DFB9; Sat, 26 Mar 2022 06:30:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C0EC1B802BD; Sat, 26 Mar 2022 13:30:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37BE2C2BBE4; Sat, 26 Mar 2022 13:30:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648301434; bh=NyuGf8K5/oZMvDcUwcrdiQlO2P8PFwGIswM7cxqDaRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fH3uZyYe9KXPYp3FSg7/S6FuQSWQ3zf8pUJdx/Me7vFSo2s6RJQ728FSEDLYDvTq1 GZyqR+NM3ZOlb2Z4mLWO4fj6lajqQNj3l37Kxh96qHfDQvuYBD1NkCpdbDmnhKOJtc Nb20kJuszKUbtuAOOfmRr4d2XPSpDXoM1zs3ZVMOD57K2A1QQrtQkWxGryxbrNdbaQ w7QKatxJTs5vBXzt+9WTnkY0TgVfNxpsGW2h6hI+TcrwNCmp32qi+49p4EJ+6vH6/l 2gH65j7rACTxgkhm+BGeGWe6KAtEijwEz+rXp+0/DH9M2EJNVrKwd/ecAg/D+bkKDf 3TmdUgaVEiB2Q== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 13E1840407; Sat, 26 Mar 2022 10:30:31 -0300 (-03) Date: Sat, 26 Mar 2022 10:30:31 -0300 From: Arnaldo Carvalho de Melo To: Leo Yan Cc: Ali Saidi , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, german.gomez@arm.com, benh@kernel.crashing.org, Nick.Forrington@arm.com, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, james.clark@arm.com, john.garry@huawei.com, jolsa@kernel.org, kjain@linux.ibm.com, lihuafei1@huawei.com, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH v4 4/4] perf mem: Support HITM for when mem_lvl_num is any Message-ID: References: <20220324183323.31414-1-alisaidi@amazon.com> <20220324183323.31414-5-alisaidi@amazon.com> <20220326062303.GC20556@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220326062303.GC20556@leoy-ThinkPad-X240s> X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Sat, Mar 26, 2022 at 02:23:03PM +0800, Leo Yan escreveu: > On Thu, Mar 24, 2022 at 06:33:23PM +0000, Ali Saidi wrote: > > For loads that hit in a the LLC snoop filter and are fulfilled from a > > higher level cache on arm64 Neoverse cores, it's not usually clear what > > the true level of the cache the data came from (i.e. a transfer from a > > core could come from it's L1 or L2). Instead of making an assumption of > > where the line came from, add support for incrementing HITM if the > > source is CACHE_ANY. > > > > Since other architectures don't seem to populate the mem_lvl_num field > > here there shouldn't be a change in functionality. > > > > Signed-off-by: Ali Saidi > > Tested-by: German Gomez > > Reviewed-by: German Gomez > > --- > > tools/perf/util/mem-events.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c > > index e5e405185498..084977cfebef 100644 > > --- a/tools/perf/util/mem-events.c > > +++ b/tools/perf/util/mem-events.c > > @@ -539,6 +539,15 @@ do { \ > > stats->ld_llchit++; > > } > > > > + /* > > + * A hit in another cores cache must mean a llc snoop > > + * filter hit > > + */ > > + if (lnum == P(LVLNUM, ANY_CACHE)) { > > + if (snoop & P(SNOOP, HITM)) > > + HITM_INC(lcl_hitm); > > + } > > This might break the memory profiling result for x86, see file > arch/x86/events/intel/ds.c: > > 97 void __init intel_pmu_pebs_data_source_skl(bool pmem) > 98 { > 99 u64 pmem_or_l4 = pmem ? LEVEL(PMEM) : LEVEL(L4); > ... > 105 pebs_data_source[0x0d] = OP_LH | LEVEL(ANY_CACHE) | REM | P(SNOOP, HITM); > 106 } > > Which means that it's possible that it's a remote access and the cache > level is ANY_CACHE, it's good to add checking for bit > PERF_MEM_REMOTE_REMOTE: > > u64 remote = data_src->mem_remote; > > /* > * A hit in another cores cache must mean a llc snoop > * filter hit > */ > if (lnum == P(LVLNUM, ANY_CACHE) && remote != P(REMOTE, REMOTE)) { > if (snoop & P(SNOOP, HITM)) > HITM_INC(lcl_hitm); > } > > Appreciate German's reviewing and testing, and sorry I jumped in very > late. I have not published this on perf/core, its just in tmp.perf/core while tests ran, so I'll remove this specific patch and rerun tests, thanks for reviewing. - Arnaldo 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 2F211C433F5 for ; Sat, 26 Mar 2022 13:32:23 +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=s/StIbiGBG/0FnBTmjF6aKvAjWqo9mcB8OgZIOm0klA=; b=YnkXb9beMyGi6B UxtM8QTf3XFG6KVDPYNGM/whgb4Z4Nim/BR4YJjfBaVQpdseWDmB1p6JBwPRDUkchvhwccDDxX9S9 NuloPIXYgjv+ikwRZPSgMTjtCnEuKuoFQpvIy5j3xYDhQR83EmY2QcdWyUnTWxBlV8x/MfuyQMUrI Nb2wHl+1/6akAy1bcz7cQSnu9hrojqrvDKSmOvSwd8KTWJeUOa3NJI6Qx+Sad72NCeLfUsuC+E33j 1fJ+KG7M6gB4a/gvvVAL3VV7VIrFcgXhwv8uOC02oTj51YS8Z6qPv514AdH/0mVCGa7Fbr8zUaN1j pmgy/Pkloowoy8c027tA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nY6V4-004Isr-8S; Sat, 26 Mar 2022 13:30:38 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nY6V2-004Isl-0h for linux-arm-kernel@bombadil.infradead.org; Sat, 26 Mar 2022 13:30:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=km9C8FpHekhujMKQE2A2RlZ2E6ABQPwf2gaHpyt7Dro=; b=eLyqjHSHV3IPcYNjLiF1k3TK2r D8a/M2TOBka2bgmaFBrcgk3QETs8IplAVX0+V1am960INe37ASiIRd3m83nGoHyFBiniqOQP+3546 DXY+T7w/xiCAZZcL/uwJHMvyDenpaTfL/Sy78VShHp0/qR/zgj9Uucqg6g6mMwknIMMbnqIlnyEHT QHvp6YPuLM5xGoL7grmPGtducd3X8NXOeI4S/D7cPJTVWockc57+0xNj98sbN3mC6HEKMJER2ne9Q dcxSPpM1Bpyl2FHGFueTnGid8haU/uoaI+gztNznD2bVtu6alSs+Z1HU9PxArWJUXtdLrBkfO53Pd URZXFDpw==; Received: from [187.19.238.43] (helo=quaco.ghostprotocols.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nY6V0-004kgZ-8m; Sat, 26 Mar 2022 13:30:34 +0000 Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 13E1840407; Sat, 26 Mar 2022 10:30:31 -0300 (-03) Date: Sat, 26 Mar 2022 10:30:31 -0300 From: Arnaldo Carvalho de Melo To: Leo Yan Cc: Ali Saidi , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, german.gomez@arm.com, benh@kernel.crashing.org, Nick.Forrington@arm.com, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, james.clark@arm.com, john.garry@huawei.com, jolsa@kernel.org, kjain@linux.ibm.com, lihuafei1@huawei.com, mark.rutland@arm.com, mathieu.poirier@linaro.org, mingo@redhat.com, namhyung@kernel.org, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH v4 4/4] perf mem: Support HITM for when mem_lvl_num is any Message-ID: References: <20220324183323.31414-1-alisaidi@amazon.com> <20220324183323.31414-5-alisaidi@amazon.com> <20220326062303.GC20556@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220326062303.GC20556@leoy-ThinkPad-X240s> X-Url: http://acmel.wordpress.com 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 Em Sat, Mar 26, 2022 at 02:23:03PM +0800, Leo Yan escreveu: > On Thu, Mar 24, 2022 at 06:33:23PM +0000, Ali Saidi wrote: > > For loads that hit in a the LLC snoop filter and are fulfilled from a > > higher level cache on arm64 Neoverse cores, it's not usually clear what > > the true level of the cache the data came from (i.e. a transfer from a > > core could come from it's L1 or L2). Instead of making an assumption of > > where the line came from, add support for incrementing HITM if the > > source is CACHE_ANY. > > > > Since other architectures don't seem to populate the mem_lvl_num field > > here there shouldn't be a change in functionality. > > > > Signed-off-by: Ali Saidi > > Tested-by: German Gomez > > Reviewed-by: German Gomez > > --- > > tools/perf/util/mem-events.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c > > index e5e405185498..084977cfebef 100644 > > --- a/tools/perf/util/mem-events.c > > +++ b/tools/perf/util/mem-events.c > > @@ -539,6 +539,15 @@ do { \ > > stats->ld_llchit++; > > } > > > > + /* > > + * A hit in another cores cache must mean a llc snoop > > + * filter hit > > + */ > > + if (lnum == P(LVLNUM, ANY_CACHE)) { > > + if (snoop & P(SNOOP, HITM)) > > + HITM_INC(lcl_hitm); > > + } > > This might break the memory profiling result for x86, see file > arch/x86/events/intel/ds.c: > > 97 void __init intel_pmu_pebs_data_source_skl(bool pmem) > 98 { > 99 u64 pmem_or_l4 = pmem ? LEVEL(PMEM) : LEVEL(L4); > ... > 105 pebs_data_source[0x0d] = OP_LH | LEVEL(ANY_CACHE) | REM | P(SNOOP, HITM); > 106 } > > Which means that it's possible that it's a remote access and the cache > level is ANY_CACHE, it's good to add checking for bit > PERF_MEM_REMOTE_REMOTE: > > u64 remote = data_src->mem_remote; > > /* > * A hit in another cores cache must mean a llc snoop > * filter hit > */ > if (lnum == P(LVLNUM, ANY_CACHE) && remote != P(REMOTE, REMOTE)) { > if (snoop & P(SNOOP, HITM)) > HITM_INC(lcl_hitm); > } > > Appreciate German's reviewing and testing, and sorry I jumped in very > late. I have not published this on perf/core, its just in tmp.perf/core while tests ran, so I'll remove this specific patch and rerun tests, thanks for reviewing. - Arnaldo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel