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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E77A2C433E3 for ; Thu, 6 Aug 2020 13:28:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E84B82310D for ; Thu, 6 Aug 2020 13:28:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Afoxen11"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ADXfnL9F" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E84B82310D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:Reply-To:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RcOrNkyLNsHndfOyp/JUOFzMoS/3e01oEBY3IQV/BZo=; b=Afoxen11K5k3LBuCaKJ2rAAcRx vUEOI/3uyJD03NAv5or8g7+XmthIgmGJ8FzLM6rsDUF+mxmD1fK1leXUEoaGXb4o7YpcxITkw/nGK 4EJEHBH9z6I2RN7N3w7RxoX9eUsZzgMBhDVDjPlfAioB8brQ9VJjqbZiZXtZqisMga+aOvfdti0uU D3B//aiMNyyRcs2JT7GW9+U3RFE0i51owFLYnyIqezUE57waAjL9EAkIwi+5GGlGaRu8KZsyxXybZ drJmBJIMfwa0qR7TUsAH/TTXRbalgiuB+8XEm3m02e5Rrnr1huk78fb55tNMmOKAFQXNn7kH9clS4 S2t4cwYQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3fvQ-00048K-4M; Thu, 06 Aug 2020 13:27:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3fvM-000478-1v for linux-arm-kernel@lists.infradead.org; Thu, 06 Aug 2020 13:27:13 +0000 Received: from paulmck-ThinkPad-P72.home (unknown [50.45.173.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C6D6E2310C; Thu, 6 Aug 2020 13:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596720430; bh=3CR47nCFqExTQ2ML0Q2q5ma+kjZk2NCJpGaKDoZNAp0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=ADXfnL9F5IxPiRumosniAILFcwP44WwOkV2KfXpn2zCUQ+j5RQzq/J9lyn1bZXQid f0qnMGIxOJgpQoFxUeFMWej2QiZ0sJcbXGL462KhzOt5H703XMuzejKaCV6bDplpPS v3AJ40qDkmnKh+NbCNNblwBjPDB36nrbvXnkSjv4= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 7476335206C1; Thu, 6 Aug 2020 06:27:10 -0700 (PDT) Date: Thu, 6 Aug 2020 06:27:10 -0700 From: "Paul E. McKenney" To: peterz@infradead.org Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting Message-ID: <20200806132710.GL4295@paulmck-ThinkPad-P72> References: <87lfiwm2bj.fsf@nanos.tec.linutronix.de> <20200803114112.mrcuupz4ir5uqlp6@skbuf> <87d047n4oh.fsf@nanos.tec.linutronix.de> <875z9zmt4i.fsf@nanos.tec.linutronix.de> <20200805134002.GQ2674@hirez.programming.kicks-ass.net> <20200805153120.GU2674@hirez.programming.kicks-ass.net> <874kpgi025.fsf@nanos.tec.linutronix.de> <20200806114545.GA2674@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200806114545.GA2674@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200806_092712_316350_E19DB84D X-CRM114-Status: GOOD ( 30.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: paulmck@kernel.org Cc: mw@semihalf.com, Anna-Maria Gleixner , catalin.marinas@arm.com, Alison Wang , linux-kernel@vger.kernel.org, leoyang.li@nxp.com, vladimir.oltean@nxp.com, Kurt Kanzenbach , Thomas Gleixner , Vladimir Oltean , will@kernel.org, Valentin Schneider , linux-arm-kernel@lists.infradead.org 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 Thu, Aug 06, 2020 at 01:45:45PM +0200, peterz@infradead.org wrote: > On Thu, Aug 06, 2020 at 11:41:06AM +0200, Thomas Gleixner wrote: > > peterz@infradead.org writes: > > > On Wed, Aug 05, 2020 at 02:56:49PM +0100, Valentin Schneider wrote: > > > > > >> I've been tempted to say the test case is a bit bogus, but am not familiar > > >> enough with the RT throttling details to stand that ground. That said, from > > >> both looking at the execution and the stress-ng source code, it seems to > > >> unconditionally spawn 32 FIFO-50 tasks (there's even an option to make > > >> these FIFO-99!!!), which is quite a crowd on monoCPU systems. > > > > > > Oh, so it's a case of: we do stupid without tuning and the system falls > > > over. I can live with that. > > > > It's not a question of whether you can live with that behaviour for a > > particular silly test case. > > > > The same happens with a single RT runaway task with enough interrupt > > load on a UP machine. Just validated that. > > Of course. > > > And that has nothing to do > > with a silly test case. Sporadic runaways due to a bug in a once per > > week code path simply can happen and having the safety net working > > depending on a config option selected or not is just wrong. > > The safety thing is concerned with RT tasks. It doesn't pretend to help > with runnaway IRQs, never has, never will. Getting into the time machine back to the 1990s... DYNIX/ptx had a discretionary mechanism to deal with excessive interrupts. There was a function that long-running interrupt handlers were supposed to call periodically that would return false if the system felt that the CPU had done enough interrupts for the time being. In that case, the interrupt handler was supposed to schedule itself for a later time, but leave the interrupt unacknowledged in order to prevent retriggering in the meantime. Of course, this mechanism would be rather less helpful in Linux. For one, Linux has way more device drivers and way more oddball devices. In contrast, the few devices that DYNIX/ptx supported were carefully selected, and the selection criteria included being able to put up with this sort of thing. Also, the fact that there was but a handful of device drivers meant that changes like this could be more easily propagated through all drivers. Also, Linux supports way more workloads. In contrast, DYNIX/ptx could pick a small percentage of each CPU that would be permitted to be used by hardware interrupt handlers. As in there are probably Linux workloads that run >90% of some poor CPU within hardware interrupt handlers. But reminiscing anyway on the off-chance that this inspires someone to come up with an idea that would work well in the Linux environment. Thanx, Paul > The further extreme is an interrupt storm, those have always taken a > machine down. > > Accounting unrelated IRQ time to RT tasks is equally wrong, the task > execution is unrelated to the IRQs. The config option at least offers > insight into where time goes -- and it's a config option because doing > time accounting on interrupts adds overhead :/ > > This really is a no-win all round. > > The only 'sensible' option here is threaded IRQs, where the IRQ line > gets disabled until the handler thread has ran, that also helps with IRQ > storms. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel