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 43F41C433FE for ; Wed, 12 Oct 2022 14:10:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BBF16B0071; Wed, 12 Oct 2022 10:10:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66A5B900002; Wed, 12 Oct 2022 10:10:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50B276B0074; Wed, 12 Oct 2022 10:10:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3E5746B0071 for ; Wed, 12 Oct 2022 10:10:42 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DE9E5A111F for ; Wed, 12 Oct 2022 14:10:41 +0000 (UTC) X-FDA: 80012483082.11.36FC954 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 28549180016 for ; Wed, 12 Oct 2022 14:10:40 +0000 (UTC) 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 2E53315A1; Wed, 12 Oct 2022 07:10:46 -0700 (PDT) Received: from wubuntu (unknown [10.57.35.175]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ED1AF3F792; Wed, 12 Oct 2022 07:10:38 -0700 (PDT) Date: Wed, 12 Oct 2022 15:10:37 +0100 From: Qais Yousef To: Hillf Danton 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 Message-ID: <20221012141037.5cm3mzmnsz5wt36z@wubuntu> References: <20221010154216.6mw7fszdaoajurvm@wubuntu> <20221011111846.284-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20221011111846.284-1-hdanton@sina.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665583841; a=rsa-sha256; cv=none; b=YqQOsv+wet+GobhhYZ2Ndem2MBdZfo3oyodJmnH9s1hbmIBGuMrSWVTPyxIuYSwcJfu3ZA AEunHtClrq7jMPs5flbbfo6laxG3XnfKsDflApIHKTVe65zr5e8ktaw6g+uea7c81srApf 5sTyx+49U/K2AOBDXuZJ+fxkcEMxk9Y= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of qais.yousef@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=qais.yousef@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665583841; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R/28uDHMy2RoMo05OA85XhCvEUZEb+ucZQL/Ql+5Xrg=; b=uObHT3XDC09F+hzuxy8FyJohtb7nJC9qosGqosqQzdJ+qILT6+KTrbOrWRw/vlZP++NgTk aqRDiOf7fY/ZVcG30PN4a6lUeQIy35QqQ9rEkyh6DOtbaBz7xfZ0+j8gHdx8qubEhsVhhs IzhfWzMS8fjhjsqachX7lZCPJpss288= X-Stat-Signature: x3bwcj99aoh1ic8ozin9shseu8iqadz9 X-Rspamd-Queue-Id: 28549180016 X-Rspam-User: X-Rspamd-Server: rspam08 Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of qais.yousef@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=qais.yousef@arm.com; dmarc=pass (policy=none) header.from=arm.com X-HE-Tag: 1665583840-558340 X-Bogosity: Ham, tests=bogofilter, spamicity=0.007994, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/11/22 19:18, Hillf Danton wrote: [...] > > 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/ I think you're mixing the two patches up. That patch is to help describe some latency requirements for CFS tasks. It has nothing to do with RT. Your suggestion to use RT scheduler is not valid as these tasks can't be converted to RT. Which is what Steve was trying to say IIUC. Generally converting normal application tasks into RT is a recipe for disaster because: 1. Misbehaving RT tasks (busy looping indefinitely) can hog the system to a halt. 2. How do you manage priorities of all these pseudo-random RT tasks each application spawns so you end up with correct resource sharing? ie: using RT policy is a privileged operation for a reason :-) The target audience for latency_nice is the average Joe task from any application that might have some latency requirements to deliver a better user experience. ie: it's not strict latency requirement. We just want to handle delays within _CFS_ part of the scheduler. By the way, your emails don't seem to make it to LKML for some reason; they show as '[not found]' on lore. https://lore.kernel.org/lkml/20221010154216.6mw7fszdaoajurvm@wubuntu/#r Thanks -- Qais Yousef