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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F8BBC433FE for ; Tue, 11 Oct 2022 11:19:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE0346B0072; Tue, 11 Oct 2022 07:19:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8FFC6B0073; Tue, 11 Oct 2022 07:19:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 957976B0074; Tue, 11 Oct 2022 07:19:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 801506B0072 for ; Tue, 11 Oct 2022 07:19:03 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4640CA0456 for ; Tue, 11 Oct 2022 11:19:03 +0000 (UTC) X-FDA: 80008421766.03.4FE0F7B Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162]) by imf09.hostedemail.com (Postfix) with ESMTP id 1F149140023 for ; Tue, 11 Oct 2022 11:19:00 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.60.223]) by sina.com (172.16.97.27) with ESMTP id 634550ED000208AE; Tue, 11 Oct 2022 19:18:06 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 86627649283662 From: Hillf Danton To: Qais Yousef Cc: John Stultz , LKML , linux-mm@kvack.org, Connor O'Brien , Peter Zijlstra , Steven Rostedt Subject: Re: [RFC PATCH v4 2/3] sched: Avoid placing RT threads on cores handling long softirqs Date: Tue, 11 Oct 2022 19:18:46 +0800 Message-Id: <20221011111846.284-1-hdanton@sina.com> In-Reply-To: <20221010154216.6mw7fszdaoajurvm@wubuntu> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665487142; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1thSI0FbE0Tybr3H+xNWvZM2SBCrllSkNPvoEkzJQ7U=; b=sU8vs502JutVg+wrAJiBhl2E3N4i33a8k3Okj4wmN4o7s7e+HIaWfdeqNDtaaBTJvdauT8 Njjw/i6Dm7aWytmOBsDTW4KL3QdtzlpDnzCXzjCPOgNVWs7Bkz3y/kv2bvuExjC8zB52PX Y9HzdkqohN/MdNi7Wz7z3/wXhKoAH0E= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665487142; a=rsa-sha256; cv=none; b=CCmua4VPimmq8E9iCmQIRz9xsJL+z6foFolj68reR5YWpKgO7AVyQE+8PmzcUwPrbRXjh/ mngZVxprrf/KliWSd3xIZPFaFcCcxaDFKVMS+/tKqdDFxo+dS63eQTZVTZwrQHxBSy+Eek Fy/PU077rFIcKtyjyJ/QDpyaQ+1uIKA= X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 1F149140023 X-Stat-Signature: 43u6woh41b657ubgzghy4o3581kqthiz Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-HE-Tag: 1665487140-202107 X-Bogosity: Ham, tests=bogofilter, spamicity=0.032859, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10 Oct 2022 16:42:16 +0100 Qais Yousef > On 10/05/22 14:01, Hillf Danton wrote: > > On 4 Oct 2022 18:13:52 -0700 John Stultz > > > On Tue, Oct 4, 2022 at 5:22 PM Hillf Danton wrote: > > > > On 3 Oct 2022 19:29:36 -0700 John Stultz > > > > > > > > > > Why would ksoftirqd preempt the rt task? > > > > > > > > > For example the kthread becomes sensitive to latency. > > > > > > Is it the case where > > > the ksoftirqd thread is configured to run at higher rtprio? > > > > > Yes, you are right. > > I don't see a problem here. If a sys-admin configures their ksoftirqds to be > a higher priority RT tasks than the audio threads, then they better know what > they're doing :-) > Thanks for taking a look. > The issue at hand here is that the softirqs boundedness is hard to control. And > the scheduling delays ensued are hard to deal with by any sys-admin. > Given "The RT scheduler is for tasks that require strick scheduling requirements over all else, including performance." [1], I would invite Steve to shed some more light on the relation between RT scheduler and performance/network throughputs. Bonus question, why softirq took no care of RT tasks, given strick scheduling requirements above? [1] https://lore.kernel.org/lkml/257E96C2-6ABD-4DD6-9B7F-771DA3D1BAAA@goodmis.org/ > Networking has actually introduced some knobs to help control that - but the > tricky bit of still being able to deliver high throughput networking while > keeping the softirq bounded to minimize scheduling delays/latencies. I think > even for PREEMPT_RT, high performance networking could be impacted to achieve > the required low latency. > > See this paper which explores this duality: > > https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.702.7571&rep=rep1&type=pdf > > > With WiFi 6 and 5G mobile networks, phones are actually expected to deliver > multi-gigabit network throughputs.