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 16F75C4708A for ; Wed, 30 Nov 2022 18:17:26 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=y4+x7yLOQ/2XuayYz041OBf8eaSO3XuYl7px3ea0H0c=; b=dfU7lUpDKVrMyS 5Q3aNjQR4ddztiwhEoOi3577HmXudtTCN79VVlh1FYuosZARNsGdFUx4Ymqcdiqh9/BSR90+LXTqy vEbEzbTCsxcRcG/v0VnPxOtaIkWpTkejWY3dZ3pl3awSGo5beShz323xiJjQBxfOEjnIxSNge0GB9 jO7ebwiYBUPokj5dyzQxIbhW/ivB7c0oguhUslLe4kzlwUv+NstIzgjowis1n9rhxPrEV+1/DbNV1 zHEBFnuoeMZtKcmKjglHuttt6Tk9cMeIg93lUBOj43NgpwyR30c0mpScz9VQg9YPe0RZKgwBACNaa i9+KLdZbhHsMwijAo/8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0RdK-001Ty5-A8; Wed, 30 Nov 2022 18:16: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 1p0RdE-001Tuq-2J for linux-arm-kernel@lists.infradead.org; Wed, 30 Nov 2022 18:16:30 +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 07E61D6E; Wed, 30 Nov 2022 10:16:31 -0800 (PST) Received: from [10.57.71.118] (unknown [10.57.71.118]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 84B0B3F73B; Wed, 30 Nov 2022 10:16:23 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2022 18:16:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 1/2] perf/arm-cmn: Cope with spurious IRQs better Content-Language: en-GB To: Geoff Blake Cc: will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221130_101628_190236_B2AF3DFD X-CRM114-Status: GOOD ( 23.62 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-11-30 16:02, Geoff Blake wrote: > 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. Kexec is not the only possible source of spurious IRQs. If they cause a problem for this driver, that cannot be robustly addressed by trying to rely on whatever software might happen to run before this driver. > 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. If arm_cmn_init_dtc() writing 0 to PMCR didn't stop the PMU then we've got bigger problems, because that's how we expect to start and stop it in normal operation. I'm not ruling out that some subtle bug in that regard might exist, since I've still not yet had a chance to reproduce and observe this behaviour on my board, but I've also not seen sufficient evidence to suggest that that is the case either. (Now that I'm looking closely, I think there *is* actually a small oversight for the DTMs, but that would lead to different symptoms than you reported) At least the writes to PMOVSR_CLR *did* clearly work, because you're seeing the "nobody cared" message from the IRQ core rather than the WARN_ON(!dtc->counters[i]) which would happen if a fresh overflow was actually asserted. Currently I would expect to see up to 4 of those messages since there can be up to 4 IRQs, but once those are all requested, enabled, and "handled", all the spurious initially-latched state should be cleared and any *new* overflows will be indicated in PMOVSR. I don't see how a single IRQ could ever be unhandled more than once anyway, if the first time disables it. Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel