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 9B2CFC02192 for ; Wed, 5 Feb 2025 13:38:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA44D280005; Wed, 5 Feb 2025 08:38:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E53F2280002; Wed, 5 Feb 2025 08:38:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1AFF280005; Wed, 5 Feb 2025 08:38:25 -0500 (EST) 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 B3C98280002 for ; Wed, 5 Feb 2025 08:38:25 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6BAC2140BE2 for ; Wed, 5 Feb 2025 13:38:25 +0000 (UTC) X-FDA: 83085995370.24.4C0C007 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id AABE4140011 for ; Wed, 5 Feb 2025 13:38:23 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf26.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738762703; a=rsa-sha256; cv=none; b=kKGfv+lc4UW1xxgdQASz6IMzcUomyxAUYGKHPDGmFzQ6HobkfVimZr6AwVoo2FZpQkkPzL ARyi+q0d8l2WPrpCtqKMSCFO6W88JKc93ZaU4sEo8p1kEGMKRYHA5pP0wI/Ya98X/hgfK3 lif6Pb1G8xeAbg43566IROPjwTHVOZg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf26.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738762703; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=51nWwId/WAs2suAzXcXJQCTnpd9bKvHUcQbbhaOEZ0k=; b=MA1+myCtnpOw6EnQ0DHDLRf1jz+E3XcDC8ikNZ1zugR4C7rTrCh+Xyl1yBXQAG9l1/hrP0 taMZKLIs9+4qvw/M/f05sRMN7yDHTn3DIXyTbOczKn4u//nP1h7zvKs0YVd+57VFqeK13k lJvOfk/aBMcEp4IYHqHahXqr1tvPxEI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B38455C6C96; Wed, 5 Feb 2025 13:37:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA8D5C4CED1; Wed, 5 Feb 2025 13:38:18 +0000 (UTC) Date: Wed, 5 Feb 2025 08:38:57 -0500 From: Steven Rostedt To: Joel Fernandes Cc: Prakash Sangappa , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Thomas Gleixner , Ankur Arora , Linus Torvalds , linux-mm@kvack.org, x86@kernel.org, Andrew Morton , luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, Boris Ostrovsky , Konrad Wilk , jgross@suse.com, Andrew.Cooper3@citrix.com, Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Mathieu Desnoyers , Clark Williams , bigeasy@linutronix.de, daniel.wagner@suse.com, Joseph Salisbury , broonie@gmail.com Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250205083857.3cc06aa7@gandalf.local.home> In-Reply-To: <20250205081635.397eacb0@gandalf.local.home> References: <9DA1FAE6-A008-4785-BDF9-541457E29807@joelfernandes.org> <20250204220418.35949317@gandalf.local.home> <20250205081635.397eacb0@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: AABE4140011 X-Rspamd-Server: rspam10 X-Stat-Signature: nj9zocjk1ggoijp7r1zgxwrfqfjpwhy3 X-HE-Tag: 1738762703-460574 X-HE-Meta: U2FsdGVkX18eg5regl7ekBZ9HtwVvTnf3r2XJwV5aoQQeAg+We2A/9aMbXsj/44uH4Vk75+XDJ0e0f1Lf4LUO+uIAbWvLetJ4Re35/KuN3VxZY2yoBqcVP3ljgYLOlHJLMp9/Gmr8uZSbuI/SPFvGMtYuZa5a6Zb7bGsMhsik+/9uNwVLajZCp16Bnraf4e0gF1Nm3OO4UmsBLNa51lfggHi5d2rJ+XbWatPAgEUDEjl6fFf9uTWGGDBJa0rX+neGNdlIjhPzgQylMUFGI8qDn+qD1sqJI7frYrrjBNpyS59+kcdCWg9CoQzQWA+mSVronwyS1KeiwAK9P7St+wYfE1VCoc5TWYGaFMk+srsXPWRVGMbeesTFOt4c+nWhbKyZ/WfB30xgyKmvJ2zuPAZHam17N9VPVQWbRS8KDQ0Y0yULB4Z3pC8Hv4YutJm3CDERh4sR3Jx5oXnTr1bvJAQ4+EAQCpNWxy/8YikNTGx9B6jbQThZKX88O1BCqlzKCRoGACGM2kRFxBIDArLUCpX4+8KT+NjdiFu40f8XGInTpEg8FKe8AuOqLVSotzqghrxwsbmAbqoQ9iX3SnHJa/qSoTXnhOsD259VMdSPNce5rfEJhJ5v1VFeTAHi8kqnmXsjEMy/9xr72tSAg/I/7yz5gZmke3cN8UV7ZtYllkJ4QwdVmavJT2DJfOCP6sCLmBgV6iCEL2WBwGclTXyvZ5/NPxG9fwGYi3Jv3baHI0Tt3Q1qLsAh4IkGYedn3veL6mQhrqRyMqRjhcC3a9qlvvJF7qMJshsKk2/Yym/Ktm1VFt59dnoCCnJT0J3aLYKj+Aab5WuyqAXfEQA3p0lNEfCvSp30td2eOfuqfQQSDC3W1+LxUKo/9GuZh/MBisMZgax3Nf7a0Bdyu7tGHVUH0JOmAHeov7NGoQ0pKe52iFxNDVdDqZ7XtNTJ5eMcWDULZmLhyXutIWrrLU26hiGZcT 01mJC14H J/iOJD+DkeQ/9UWWrEUG0vf5D2nrF0HKxzo3LTs3songEBjhiCGZVWf21drhLm0QxgN28i/DOfVlZ/SJ1TAQiFLzbLbURzoPjKoUpJ2mtPDepgaN8cYGT5VIteK0dNR9j9oXUjNUSLnFGbvHxOFP7JldMRsDogDWIi8lbubG95sREb3xmwSMujn5ICbcySiE5DOzFKYDjPuq1u0euAV2WomjLdngwJ0wMw6+S1WsAC+3ZQ1oxQZR3fGDbs6r/sBGuLv48GZNk6HjWmGCeqzrLzsilAwC1HcTc3KKzzH8GqXfE91yobwi0vROOnfQuRoYyNEhQMHuApiHFkFX0oVby216I4oDV7I0DJNJSii8zCgzmtQAzwOiDkztFhuVJPGHrlTnW X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 5 Feb 2025 08:16:35 -0500 Steven Rostedt wrote: > Correct. And why I don't think this should be used for RT. It's SCHED_OTHER > that doesn't have any control of the sched tick, where this hint can help. Honestly, I don't care that much if it is used on all preemption models, but I do care if it affects RT tasks. The LAZY flag just happens to let us know if the next schedule is mandatory or not. NEED_RESCHED_LAZY means, this schedule is not that important, where as the NEED_RESCHED means it is. That's why I picked that to decide if the task can get extended or not. Has nothing to do with the preemption method. The preemption method currently sets that flag. Now we could just change when NEED_RESCHED_LAZY is set and this could work with all preemption methods. To explain this better. Currently we have: TYPE | Sched Tick | RT Wakeup | ===========+=======================+======================+ None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY | -----------+-----------------------+----------------------+ Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------+----------------------+ Full | NEED_RESCHED | NEED_RESCHED | -----------+-----------------------+----------------------+ Perhaps if we do: TYPE | Sched Tick | RT Wakeup | ===========+===================================+======================+ None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY | -----------+-----------------------------------+----------------------+ Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------------------+----------------------+ Full | NEED_RESCHED or NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------------------+----------------------+ Where on the scheduler tick, for PREEMPT_FULL (and even PREEMPT_RT), we set NEED_RESCHED if the task is in the kernel and NEED_RESCHED_LAZY if it is in user space then this patch will work in all preemption methods. As the LAZY bit will decide if the task gets extended or not. That is, any SCHED_OTHER task that is being preempted due to its scheduler tick can be granted 50us more, regardless of the preemption method. Now on PREEMPT_NONE, it may even get to preempt a RT task a bit more, but RT tasks have more to worry about if they are running on a PREEMPT_NONE system anyway! -- Steve