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 D58B7C433EF for ; Fri, 8 Apr 2022 01:08:15 +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=9jxZtOEKwfkkAKTmzuvstdN963PS2H8hy9DqW/x+Fo8=; b=dzE345074gYoDA oHvV1vDSKpT87SLbdbMLKLDicflpyndavc4g3UxPVnGXF5cn1s7/tJqcMNtN8EIz8evbg0wqKDKla GUrZy/xl9H7cTIHtcyL+KudiDgOuMXSK7312Hwof8QzLtMj2b43RTOGC/E2uTDxSLMjN5IzlmYOo9 1Y5ROE6HcUZUY0kXfTMa5twr6yi9/9ry5HqtSvRQ4ewkG8UmgylCO6x0j3pdU9R8tqvZyEq64H63j 1jB2EpkVFojepDEPKQ38dHycyN0mWmT56BxTpqmk/ANDjxzU1Kmmk/vg87vWdSzpIuRCsDqL7wPOv m4TgWZzyHi1GqtT+CSMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncd5S-00EVN3-MR; Fri, 08 Apr 2022 01:06:54 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncd5P-00EVMD-4o for linux-arm-kernel@lists.infradead.org; Fri, 08 Apr 2022 01:06:52 +0000 Received: by mail-pg1-x536.google.com with SMTP id 32so4318894pgl.4 for ; Thu, 07 Apr 2022 18:06:47 -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=L9V8khs2Pw9oU0MoU+h4vOiXzP1pcSaWg3ChFlkePHo=; b=vo6sJW3cBrcN6VOxtEd/FAbg7J4ohvujEc1YI4GFeoJGmubYimrIMWVg4e0SLCS9Vj spa5FKQkLJaElouFG7Eucrhp+SDVBXLSKlmpDfjUlhmkX0XEDlvcKuIi/POHIBlyJvAP rmzeqAM+ByuXCtq4ZThmrWSVfq/N6otsXfCQaaK6Dw4IDAzpiIcze7d2mgQiZTTjkDQf gNLQqaKqr0ui7cMTfO9SlJOub05PARpSUvGFFD95r0xmCzsewchhT4RCaRg9Zlya3V5V Idc8Si5TdIz9d68/Gg7bJRcw6XR5iA9PKeJEXPIXVBlaHqTHcifguf2AeFl2C8rPyBVx o4oA== 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=L9V8khs2Pw9oU0MoU+h4vOiXzP1pcSaWg3ChFlkePHo=; b=r/ckmNJTh9/QEk+HvH777pYp/FNkA9xDflIBjxEkA0AoQeVcqEqUb0Sg12TLand1xx GGDFWCYCvhl2HpEXm/65PSPVGXlxeB1QZxCXyI61AifIcDTny5FuGu2INJKnE3AGACNe 3obrJYmUHHDSPi/RujuFn6SvqSY7965yo5f86NNVc/DIT8VPAWVRg7yGGqP1qefJYwZv uxTlGf3WiuVBDfhtlX0NLcIZo3NhawrhRmQ6/vq3xDShgqF7UwgIyqsrtFIBASqW0HKg CrkEFsuU1gORGsgCYBiAPmm68R9ogx7qNPRH7ATJvfDiCI9E1KDUYTUxTp5Oy/bTfzJN +0AA== X-Gm-Message-State: AOAM533o0GJprxrGm61cOdyYSqCsrXRWa2WFBHr4GKhF8m6igaNgUruL ytPCbkNI0kXtwwkzZZClHXPKYA== X-Google-Smtp-Source: ABdhPJzbk8Fz0L2VMqW+YNbTDb7UYvDsO8em7MsCInr1vKUKjCrkwBfYbotqI1S94QdwLgc1/2hCpw== X-Received: by 2002:a05:6a00:3316:b0:4fa:80fd:f3f6 with SMTP id cq22-20020a056a00331600b004fa80fdf3f6mr16682002pfb.65.1649380006462; Thu, 07 Apr 2022 18:06:46 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([134.195.101.46]) by smtp.gmail.com with ESMTPSA id a11-20020a056a000c8b00b004fade889fb3sm25226056pfv.18.2022.04.07.18.06.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 18:06:45 -0700 (PDT) Date: Fri, 8 Apr 2022 09:06:35 +0800 From: Leo Yan To: Ali Saidi Cc: Nick.Forrington@arm.com, 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@kernel.org, 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 Subject: Re: [PATCH v4 2/4] perf arm-spe: Use SPE data source for neoverse cores Message-ID: <20220408010635.GA973239@leoy-ThinkPad-X240s> References: <20220404151218.GA898573@leoy-ThinkPad-X240s> <20220406210017.11887-1-alisaidi@amazon.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220406210017.11887-1-alisaidi@amazon.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_180651_263662_58BDAEEA X-CRM114-Status: GOOD ( 27.28 ) 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 Wed, Apr 06, 2022 at 09:00:17PM +0000, Ali Saidi wrote: > On Mon, 4 Apr 2022 15:12:18 +0000, Leo Yan wrote: > > On Sun, Apr 03, 2022 at 08:33:37PM +0000, Ali Saidi wrote: [...] > > > PEER_CORE -> MEM_SNOOP_PEER + L2 > > > PEER_CLSTR -> MEM_SNOOP_PEER + L3 > > > PEER_LCL_CLSTR -> MEM_SNOOP_PEER + L3 (since newer neoverse cores don't support > > > the clusters and the existing commercial implementations don't have them). > > > > Generally, this idea is fine for me. > > Great. > > Now the next tricky thing. Since we're not using HITM for recording the memory > events, the question becomes for the c2c output should we output the SNOOP_PEER > events as if they are HITM events with a clarification in the perf-c2c man page > or effectively duplicate all the lcl_hitm logic, which is a fair amount, in > perf c2c to add a column and sort option? I think we need to handle both load and store operations in 'perf c2c' tool. For the load operation, in the 'cache line details' view, we need to support 'snoop_peer' conlumn; and since Arm SPE doesn't give any data source info for store opeartion, so my plan is to add an extra conlumn 'Other' based on the two existed conlumns 'L1 Hit' and 'L1 Miss'. Could you leave this part for me? I will respin my patch set for extend 'perf c2c' for this (and hope can support the old Arm SPE trace data). Please note, when you spin new patch set, you need to take care for the store operations. In the current patch set, it will wrongly always set L1 hit for all store operations due to the data source field is always zero. My understanding is for all store operations, we need to set the cache level as PERF_MEM_LVLNUM_ANY_CACHE and snoop type as PERF_MEM_SNOOP_NA. > > Following your suggestion, if we connect the concepts PoC and PoU in Arm > > reference manual, we can extend the snooping mode with MEM_SNOOP_POU > > (for PoU) and MEM_SNOOP_POC (for PoC), so: > > > > PEER_CORE -> MEM_SNOOP_POU + L2 > > PEER_LCL_CLSTR -> MEM_SNOOP_POU + L3 > > PEER_CLSTR -> MEM_SNOOP_POC + L3 > > > > Seems to me, we could consider for this. If this is over complexity or > > even I said any wrong concepts for this, please use your method. > > I think this adds a lot of complexity and reduces clarity. Some systems > implement coherent icaches and the PoU would be the L1 cache, others don't so > that would be the L2 (or wherever there is a unified cache). Similarly, with the > point of coherency, some systems would consider that dram, but other systems > have transparent LLCs and it would be the LLC. Okay, it's fine for me to move forward to use MEM_SNOOP_PEER as the solution. Since German is looking into this part, @German, if you have any comment on this part, just let us know. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel