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 1D327C4321E for ; Wed, 30 Nov 2022 16:08:50 +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:MIME-Version:References:Message-ID: In-Reply-To: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=XVzueycJtmlVy4vOgBhIMwuvI0vLSztguWBYr2vt+VE=; b=Wepku/Ut5jIAF4 vylvHJSNH5tNcr1jsOkJsBNXgSNFdAUUg6JRqaTXhImeBhDSIQaiGiKiZLnTNLew1EAycMrp4uZSH mP8r+oCHZbbEOVQMOwNXrfwaiQrm4KC9xv2v2WeqlfRqf6GqXRLvNbGAZgY2TBCaNXHN4VRl7oC/S 6t9syCGychsltJmEHw5DqmzHQiWwBd9RY6eQd+diS/wICo/F3VrKIetbozyLXa89wQc6wmHv3geAO kcpj2Fix7aRjb0RSVT5NtRMNSFxvR3cDTtmkr23OQ/ZS5hNwxjrqAyiRs5kSH3MyvOemcapeEeitZ PK9fDL8x6f9KqNbBR2BA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0PcV-000IY0-UG; Wed, 30 Nov 2022 16:07:36 +0000 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0PcS-000IPK-Hl for linux-arm-kernel@lists.infradead.org; Wed, 30 Nov 2022 16:07:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1669824453; x=1701360453; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4HeO5q4X4CFfVFHYtGp/Sa2VvrBi6GbKhIVzYVDzgWc=; b=va1Xz+NKhTgA6A+tc9IZnaAyJDtv7PhZ1j1Bn/DX3Y+k35dXyves8K60 op1PbkkPf+U9LSb7Jt2EsIX4du0j6k2Hryn1PV+2P/xtaE9kNg24vUbJI FF6yKaXdGcUZqmhyKb+y7N86Ijr5Fh5hP27yFhkuDEINOXvynYpgVHF2I g=; X-IronPort-AV: E=Sophos;i="5.96,206,1665446400"; d="scan'208";a="285619910" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-pdx-2a-m6i4x-d40ec5a9.us-west-2.amazon.com) ([10.25.36.210]) by smtp-border-fw-9102.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 16:07:15 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2a-m6i4x-d40ec5a9.us-west-2.amazon.com (Postfix) with ESMTPS id 92F5C4161F; Wed, 30 Nov 2022 16:07:11 +0000 (UTC) Received: from EX19D003UWC001.ant.amazon.com (10.13.138.144) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 30 Nov 2022 16:07:11 +0000 Received: from [192.168.3.46] (10.43.160.223) by EX19D003UWC001.ant.amazon.com (10.13.138.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.20; Wed, 30 Nov 2022 16:07:10 +0000 Date: Wed, 30 Nov 2022 10:02:58 -0600 From: Geoff Blake To: Robin Murphy CC: , , , Subject: Re: [PATCH 1/2] perf/arm-cmn: Cope with spurious IRQs better In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-Originating-IP: [10.43.160.223] X-ClientProxiedBy: EX13D28UWB004.ant.amazon.com (10.43.161.56) To EX19D003UWC001.ant.amazon.com (10.13.138.144) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221130_080732_683079_5FC46845 X-CRM114-Status: GOOD ( 13.57 ) 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 Robin, >From my perspective, this is a worse solution as now we're sweeping an issue under the rug and consuming CPU cycles handling IRQs we should not be getting in the first place. While an overflow IRQ from the cmn should not be high frequency, there is a non-zero chance in the future it could be and this could lead to a very hard to debug performance issue instead of the current problem, which is discovering we need to clean up better from a noisy kernel message. The driver as best I can grok currently is optimized to limit the amount of register writes for the common use-case, which is setting and unsetting events, so all the wiring for the PMU to feed events to the DTC is done up front on load: DTC_CTL's DT_EN bit is set immediately during probe, as is OVFL_INTR_EN. All the DN states and DTM PMU_CONFIG_PMU_EN is deferred for when an event is actually set, and here we go through all of them anyways for each event unless its bynodeid, so the expense of setting events grows linearly with the mesh size anyways. Doing a one time scan on remove/shutdown to reset everything to a clean state seems like a wash performance wise and wanting to keep just a single register write doesn't make much sense to me. Should I instead pull this step out as a generic initialization step that can live as a single chunk of code to make it better for maintainability? Would that be a better solution? - Geoff _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel