Received: by 2002:a05:6a10:83d0:0:0:0:0 with SMTP id o16csp44360pxh; Thu, 7 Apr 2022 13:28:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy84suYMgmjEPHkWdPk/Q+YX4IKG0HnFMttSNUb5Jhdj/4yt/LBkqfm3jIC94/KCipwRu7I X-Received: by 2002:a63:d64d:0:b0:374:6edc:989c with SMTP id d13-20020a63d64d000000b003746edc989cmr12672715pgj.434.1649363311404; Thu, 07 Apr 2022 13:28:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649363311; cv=none; d=google.com; s=arc-20160816; b=pNoGNwAlc4ViSpNhxkHWvv+dOMJMTtR70wsvq6N7yBZB/tZt3P3O+hJa73htBKBKFy LpxR3K7ZjQc0LkLoSTluW9Rl5BuJ/bQKFt0PBOrEgUOdFEsZpS2Zg9W5saja/iGXqtfb 9Ksem9VGhfaet5wBPDWwwhWfHYdSPdW141vT5hzMMipeXtcptqW7tp+EZ2bm5MozKxfX qT1qtz0L3Qt0GxJ6QhxNgqZWylVm9gafCfGX4nfvh9Gy6Du6UoP4wwoSC+4G57fvT/Ez 6tutkUEdVBKGlvPTtBZyCHsTjWsOxDyDHVmfPcYglBEi5npIzOafCZhYI75yNvJ6vzpG XN0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=87yozQTn9XZah1bvCnkxIcox3KB6N7YQEw3AjKN6aFQ=; b=i3emusnN0Bx0sF0am06DAB+gZk0KLDYzCzBj4qUW5ezEI2mAqANupUSMNr0ROv//re orLhEt1EBKTSTNhkkRWv+X0E78b0p6egv1gp1sFqYJuMDVZYK/qWxSCN/QbkLJaYAFhU 7vHwIP9fcF8HIVz7VmwID1hiqXIYBR4/a4VGQ3Wpc3TDhOi09AZrJr6aAUCVS4pLQqWr RuC5nNiprLXS37XNWhrZeW/piAVrYWV4IwSrbGmXOI9MObOM3yuwbpGSjOpJNxuQj+vv +HlnlFCcPP5SaXhILCN8jyFpaHpexcTf1yp7N8e5VDK4+oOBXxIs8hthFgrYp8WsKkjY 1YXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p25-20020a637f59000000b003988eefb957si19214424pgn.536.2022.04.07.13.28.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 13:28:31 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4C33B365014; Thu, 7 Apr 2022 12:43:20 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344624AbiDGP0y (ORCPT + 99 others); Thu, 7 Apr 2022 11:26:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344635AbiDGP0w (ORCPT ); Thu, 7 Apr 2022 11:26:52 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2A91B21B2FD; Thu, 7 Apr 2022 08:24:52 -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 B208112FC; Thu, 7 Apr 2022 08:24:46 -0700 (PDT) Received: from [10.1.26.146] (e127744.cambridge.arm.com [10.1.26.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1E6743F73B; Thu, 7 Apr 2022 08:24:41 -0700 (PDT) Subject: Re: [PATCH v4 2/4] perf arm-spe: Use SPE data source for neoverse cores To: Ali Saidi , Leo Yan Cc: Nick.Forrington@arm.com, acme@kernel.org, alexander.shishkin@linux.intel.com, andrew.kilroy@arm.com, benh@kernel.crashing.org, 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 References: <20220328130547.GA360814@leoy-ThinkPad-X240s> <20220329143214.12707-1-alisaidi@amazon.com> <4710b4b2-5dcd-00a4-3976-1bd5340f401d@arm.com> <20220331124425.GB1704284@leoy-ThinkPad-X240s> From: German Gomez Message-ID: Date: Thu, 7 Apr 2022 16:24:35 +0100 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: <20220331124425.GB1704284@leoy-ThinkPad-X240s> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 31/03/2022 13:44, Leo Yan wrote: > [...] >>> I'd like to do this in a separate patch, but I have one other proposal. The >>> Neoverse cores L2 is strictly inclusive of the L1, so even if it's in the L1, >>> it's also in the L2. Given that the Graviton systems and afaik the Ampere >>> systems don't have any cache between the L2 and the SLC, thus anything from >>> PEER_CORE, LCL_CLSTR, or PEER_CLSTR would hit in the L2, perhaps we >>> should just set L2 for these cases? German, are you good with this for now? >> Sorry for the delay. I'd like to also check this with someone. I'll try >> to get back asap. In the meantime, if this approach is also OK with Leo, >> I think it would be fine by me. Sorry for the delay. Yeah setting it to L2 indeed looks reasonable for now. Somebody brought up the case of running SPE in a heterogeneousĀ  system, but also we think might be beyond the scope of this change. One very minor nit though. Would you be ok with renaming LCL to LOCALĀ  and CLSTR to CLUSTER? I sometimes mistead the former as "LLC". > Thanks for the checking internally. Let me just bring up my another > thinking (sorry that my suggestion is float): another choice is we set > ANY_CACHE as cache level if we are not certain the cache level, and > extend snoop field to indicate the snooping logics, like: > > PERF_MEM_SNOOP_PEER_CORE > PERF_MEM_SNOOP_LCL_CLSTR > PERF_MEM_SNOOP_PEER_CLSTR > > Seems to me, we doing this is not only for cache level, it's more > important for users to know the variant cost for involving different > snooping logics. > > Thanks, > Leo I see there's been some more messages I need to catch up with. Is theĀ  intention to extend the PERF_MEM_* flags for this cset, or will it be left for a later change? In any case, I'd be keen to take another look at it and try to bring some more eyes into this. Thanks, German