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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 ECAACC433DF for ; Thu, 6 Aug 2020 11:47:13 +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 A71B2206C3 for ; Thu, 6 Aug 2020 11:47:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VeitZwdq"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="mN0bUej5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A71B2206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.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:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=j0Zs7/kK64jd361nDb1lZtEpFBbYv7y2ZQ+XS/It2DQ=; b=VeitZwdqL5AjL13D3L8yVq4mX 8WZ2WYVla6gQD1zuKfaM8ipNmdZqjJqZ2rsat97aLoH/RfUzsoeCg/ujDEnr2/QM0KxqqHoEibwy8 Wfn9pZ2ecq1hgNhpmZJmiC9sfo38PEcR4q6Ydfu/P31nVxYaK48bl6lH+E/M211IO2B07/HLkX9re +NBtJXe7LNz7kMV5L25GNPRm/icZ+jZfWOoZLtfy8TH9a90ofVrAoG65R4vQStqJveyFdOzn670xG zCHpuAI4QejUVIfoQ11EzRrwr0BzWjGQemBvsp4k/z4dUosmLRPiImHMZpV7PJaOa/umV0vM5FwLB cv6lrBmig==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3eLH-0008BN-H5; Thu, 06 Aug 2020 11:45:51 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3eLF-0008B0-22 for linux-arm-kernel@merlin.infradead.org; Thu, 06 Aug 2020 11:45:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mb6Pcn8GA5zfSJfRuHB/gTx/1/FB8gTP4+5zdNlmjw4=; b=mN0bUej55+bDD24xUR681m+tcG ZB+jUoAwwJi6Gl04PymXuUnXRU+GAYQndtdvwKjFt78vP+XYFznahcCJZydD337JRLxZHyYXoy9Jk GQzh7jleA1wnTGkCGKk5Ekch+iU0Vxm2YhVSnub0AGBvR70dx0+7r4UN2b+wghZI3LXy8LPvy6oOn RG4w9ujsEHcqSiC/iNVhVjJuChPM1kCFrs3k4L7mJQ6u2woPIMyznJ59SW8wMI0RfyBfyoBTslya9 vLGoz7GUsA3GKoT03uk0SZthK0XrevlLBEcB2RyH9Nv4QTNz/OWuCIslqGHMXa7OIMot3719dAmbr 3xZ3HOcQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3eLC-0006pL-Cf; Thu, 06 Aug 2020 11:45:46 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id AECBF301A66; Thu, 6 Aug 2020 13:45:45 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 8CCD2220F91B8; Thu, 6 Aug 2020 13:45:45 +0200 (CEST) Date: Thu, 6 Aug 2020 13:45:45 +0200 From: peterz@infradead.org To: Thomas Gleixner Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting Message-ID: <20200806114545.GA2674@hirez.programming.kicks-ass.net> References: <873654m9zi.fsf@kurt> <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <874kpgi025.fsf@nanos.tec.linutronix.de> 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: , Cc: mw@semihalf.com, paulmck@kernel.org, Anna-Maria Gleixner , catalin.marinas@arm.com, Alison Wang , linux-kernel@vger.kernel.org, leoyang.li@nxp.com, vladimir.oltean@nxp.com, Kurt Kanzenbach , 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 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. 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