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 3B552C433F5 for ; Mon, 24 Jan 2022 17:25: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:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=Hi+VhnLkJ7T9VHsb3RoiYWrb1TqVVK5WlEhN5J7fc/E=; b=Mu6nSGO4EJgB+rc13kPsU8f5Ue mrXvwjNuntBdTnraGKM1b2TUNQGl7RoiVCHEZ+b1WSa6bRbvxsPa2v+e5gSkN42jAUVWbpwLHWS16 2mL9cFD6tee/9fM88l/D1yGAxHlyXEllA9ptPYPHcLF85L8IwvlaVWnj5I0yPErh2hHSaAL/yjsR7 Nl39eyBg6kXDzsCSGl/nor15jaihzY6Ho76u7i0/HPZNfhGSwkzG0Wb3CLGQ4ELALskMZmw7qAFle yOQ2lCG1ZpYLRGLyAjLZQVhn+1dYGzbLuGiC90HI/e2LV3Y2JE6VGWOFyyy3rMKqn7FZX2cJ9i8Sf wD4RCLgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nC350-004Cip-1P; Mon, 24 Jan 2022 17:24:34 +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 1nC34w-004Ci8-LR for linux-arm-kernel@lists.infradead.org; Mon, 24 Jan 2022 17:24:32 +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 D08F4D6E; Mon, 24 Jan 2022 09:24:29 -0800 (PST) Received: from [10.57.39.131] (unknown [10.57.39.131]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 47DF13F766; Mon, 24 Jan 2022 09:24:27 -0800 (PST) Subject: Re: [PATCH] perf arm-spe: Use SPE data source for neoverse cores To: Ali Saidi , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Leo Yan Cc: benh@kernel.crashing.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , John Garry , Will Deacon , Mathieu Poirier , Leo Yan , German Gomez , Andrew Kilroy References: <20220121182456.13538-1-alisaidi@amazon.com> From: James Clark Message-ID: <0ba26f30-6978-36ad-f7d0-7b8465648e54@arm.com> Date: Mon, 24 Jan 2022 17:24:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220121182456.13538-1-alisaidi@amazon.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220124_092430_827380_1330D261 X-CRM114-Status: GOOD ( 28.21 ) 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 21/01/2022 18:24, Ali Saidi wrote: > When synthesizing data from SPE, augment the type with source information > for Arm Neoverse cores. The field is IMPLDEF but the Neoverse cores all use > the same encoding. I can't find encoding information for any other SPE > implementations to unify their choices with Arm's thus that is left for future > work. > > This changes enables the expected behavior of perf c2c on a system with SPE where > lines that are shared among multiple cores show up in perf c2c output. > > Signed-off-by: Ali Saidi > --- > .../util/arm-spe-decoder/arm-spe-decoder.c | 1 + > .../util/arm-spe-decoder/arm-spe-decoder.h | 12 +++++ > tools/perf/util/arm-spe.c | 48 ++++++++++++++----- > 3 files changed, 49 insertions(+), 12 deletions(-) > [...] > +static u64 arm_spe__synth_data_source(const struct arm_spe_record *record, u64 midr) > { > union perf_mem_data_src data_src = { 0 }; > + bool is_neoverse = is_midr_in_range(midr, neoverse_spe); > > if (record->op == ARM_SPE_LD) > data_src.mem_op = PERF_MEM_OP_LOAD; > @@ -409,19 +418,30 @@ static u64 arm_spe__synth_data_source(const struct arm_spe_record *record) > data_src.mem_op = PERF_MEM_OP_STORE; > > if (record->type & (ARM_SPE_LLC_ACCESS | ARM_SPE_LLC_MISS)) { > - data_src.mem_lvl = PERF_MEM_LVL_L3; > + if (is_neoverse && record->source == ARM_SPE_NV_DRAM) { > + data_src.mem_lvl = PERF_MEM_LVL_LOC_RAM | PERF_MEM_LVL_HIT; > + } else if (is_neoverse && record->source == ARM_SPE_NV_PEER_CLSTR) { > + data_src.mem_snoop = PERF_MEM_SNOOP_HITM; I'm not following how LLC_ACCESS | LLC_MISS ends up as HITM in this case (ARM_SPE_NV_PEER_CLSTR)? I thought there was no way to determine a HITM from SPE. Wouldn't one of the other values like PERF_MEM_SNOOP_MISS be more accurate? > + data_src.mem_lvl = PERF_MEM_LVL_L3 | PERF_MEM_LVL_HIT; This one also adds PERF_MEM_LVL_HIT even though the check of "if (record->type & ARM_SPE_LLC_MISS)" hasn't happened yet. Maybe some comments would make it a bit clearer, but at the moment it's not obvious how the result is derived because there are some things that don't add up like ARM_SPE_LLC_MISS == PERF_MEM_LVL_HIT. > + } else { > + data_src.mem_lvl = PERF_MEM_LVL_L3;> > - if (record->type & ARM_SPE_LLC_MISS) > - data_src.mem_lvl |= PERF_MEM_LVL_MISS; > - else > - data_src.mem_lvl |= PERF_MEM_LVL_HIT; > + if (record->type & ARM_SPE_LLC_MISS) > + data_src.mem_lvl |= PERF_MEM_LVL_MISS; > + else > + data_src.mem_lvl |= PERF_MEM_LVL_HIT; > + } > } else if (record->type & (ARM_SPE_L1D_ACCESS | ARM_SPE_L1D_MISS)) { > - data_src.mem_lvl = PERF_MEM_LVL_L1; > + if (is_neoverse && record->source == ARM_SPE_NV_L2) { > + data_src.mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT; > + } else { > + data_src.mem_lvl = PERF_MEM_LVL_L1; > > - if (record->type & ARM_SPE_L1D_MISS) > - data_src.mem_lvl |= PERF_MEM_LVL_MISS; > - else > - data_src.mem_lvl |= PERF_MEM_LVL_HIT; > + if (record->type & ARM_SPE_L1D_MISS) > + data_src.mem_lvl |= PERF_MEM_LVL_MISS; > + else > + data_src.mem_lvl |= PERF_MEM_LVL_HIT; > + } > } > > if (record->type & ARM_SPE_REMOTE_ACCESS) > @@ -446,7 +466,7 @@ static int arm_spe_sample(struct arm_spe_queue *speq) > u64 data_src; > int err; > > - data_src = arm_spe__synth_data_source(record); > + data_src = arm_spe__synth_data_source(record, spe->midr); > > if (spe->sample_flc) { > if (record->type & ARM_SPE_L1D_MISS) { > @@ -796,6 +816,10 @@ static int arm_spe_process_event(struct perf_session *session, > u64 timestamp; > struct arm_spe *spe = container_of(session->auxtrace, > struct arm_spe, auxtrace); > + const char *cpuid = perf_env__cpuid(session->evlist->env); > + u64 midr = strtol(cpuid, NULL, 16); > + > + spe->midr = midr; > > if (dump_trace) > return 0; > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel