Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2094963pxk; Mon, 14 Sep 2020 04:47:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZx5NoYNkHslGQbkd132wQJouvEof88Eya18QUESvFHufp/9H7LRpE3MODiaQGnXSlpeN3 X-Received: by 2002:a17:907:648:: with SMTP id wq8mr14908112ejb.291.1600084065212; Mon, 14 Sep 2020 04:47:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600084065; cv=none; d=google.com; s=arc-20160816; b=u7IrfP2ytXhhSBwcweCghQmNrJeY9ax6JGMrFhq+s+oVevdN4RyJNhH8Nha3XDNjJx 8PSHsGY2gyQAcn46HIMzpPMOMJvq5VRgV8LF+P+ceYkzsRi0u4x8JaLgxAwUaWiwmewy A9PH8kUu1gUo2RnXWMGLdiIWSdAvWM5hLUca0YQBKwPd3oKYGzNc8wX6KhI67pvsRafP mLUtn6AFJ7EhX1kTqwzwIrU5+Twmv2OQi/E6VtFnjW3fTo99kbwALlv3B0OaP20gJOlX 4KwOfQGe7P748+uzOHknTZRa8fPgfcEmQFN4oaKoI+AKdvAx/Mg6ql/+1rICZHni59uV F+rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7mADQty4cGy4fYyz9CUFEVjuXB+AvetCdF3sMNsT1yQ=; b=vVm2H7f6D+NIkmejFNRLnIPersfStbDkxps1cxP+vUoCWjqZ5sMgkJpgtw9euzteRq wG6UVhWmzaZzK/hAErb/GxO4+MugX99krsPjnhEWq1+7rUl9Z/17W3YgJ4dP0D6RIfRG W4ungfWNyy5aJfEO+Oy1LocTRPXOF93qkpoWV3ASYLjTaaZF2erws6b7QcC8X0gz/pse uiiLLpexDaqPMjOzVFZdvURi8Uv/DwMxSyaK7yDefyEw9X4niT0/pGL3PBvJsCBr8xD9 G27TQzGQLiBZF5TaslQPOnkYZBz8D7OT+S82/21VCbX8ZnWxvAEeUBCwylnfrLLzliAK zb1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n12si7021802eji.393.2020.09.14.04.47.22; Mon, 14 Sep 2020 04:47:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726114AbgINLpQ (ORCPT + 99 others); Mon, 14 Sep 2020 07:45:16 -0400 Received: from foss.arm.com ([217.140.110.172]:35062 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726066AbgINLlU (ORCPT ); Mon, 14 Sep 2020 07:41:20 -0400 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 BE8AF106F; Mon, 14 Sep 2020 04:41:14 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5361C3F68F; Mon, 14 Sep 2020 04:41:13 -0700 (PDT) Date: Mon, 14 Sep 2020 12:41:11 +0100 From: Qais Yousef To: John Dias Cc: Peter Zijlstra , qianjun.kernel@gmail.com, tglx@linutronix.de, will@kernel.org, luto@kernel.org, LKML , laoar.shao@gmail.com, urezki@gmail.com, Wei Wang , Quentin Perret Subject: Re: [PATCH V6 1/1] Softirq:avoid large sched delay from the pending softirqs Message-ID: <20200914114110.esjlzcukfx5emkke@e107158-lin.cambridge.arm.com> References: <20200909090931.8836-1-qianjun.kernel@gmail.com> <20200911164644.eqjqjucvqfvrmr67@e107158-lin.cambridge.arm.com> <20200911182832.GL1362448@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/11/20 12:14, John Dias wrote: > I agree that the rt-softirq interaction patches are a gross hack (and I > wrote the original versions, so it's my grossness). The problem is that > even a 1ms delay in executing those low-latency audio threads is enough to > cause obvious glitching in audio under very real circumstances, which is > not an acceptable user experience -- and some softirq handlers run for >1ms > on their own. (And 1ms is a high upper bound, not a median target.) AFAIK professional audio apps have the toughest limit of sub 10ms. 120MHz screens impose a stricter limit on display pipeline too to finish its frame in 8ms. 1ms is too short and approaches PREEMPT_RT realm. Is it possible to expand on the use case here? What application requires this constraint? Thanks -- Qais Yousef