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 E813FC02194 for ; Thu, 6 Feb 2025 13:44:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E68B28000F; Thu, 6 Feb 2025 08:44:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 79602280002; Thu, 6 Feb 2025 08:44:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65DD428000F; Thu, 6 Feb 2025 08:44:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 45C2E280002 for ; Thu, 6 Feb 2025 08:44:16 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EAC4F4B5A7 for ; Thu, 6 Feb 2025 13:44:15 +0000 (UTC) X-FDA: 83089638870.01.18328F8 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf21.hostedemail.com (Postfix) with ESMTP id 333BD1C006B for ; Thu, 6 Feb 2025 13:44:13 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=1VpsuZg8; dkim=pass header.d=linutronix.de header.s=2020e header.b=IgZKsIgD; spf=pass (imf21.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738849454; 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:dkim-signature; bh=JOX9N9Jl0n76pdFc/nqI2BFCfJhd+hMrjbMMQLGqsc8=; b=Snkl5CdcoLxJnR7EpiO2K3IGk3A1LdEqG1/i3i8bvUqB/uQZnQk+maRGmHIVyznfmtF9o4 9h5qAVp+WLd+cnMCO4/0benA22LrF3JXNM3mjJGFq9hjgq1tvROo1M+LqQaXRxGfZOcfvL zUPLYR9Bf/Wvl6HRFGdLw/1DVpmhdVU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=1VpsuZg8; dkim=pass header.d=linutronix.de header.s=2020e header.b=IgZKsIgD; spf=pass (imf21.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738849454; a=rsa-sha256; cv=none; b=06LefMY1Xz+bzA1UWHlUntYgAUadAMsEYYOK2NjDqcSHFtbeYG35NI7lS3WSGzAhS8yj5U NmhOWn9bKIwD8ySG4MwQuvhM6YHO6zvVEZWZNVWkgVOtb1cbl6FWh95dHEwZQ9OaHsoSVf sJuj+GECBORg7FixQ73YS58oGyXTvT0= Date: Thu, 6 Feb 2025 14:44:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738849450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JOX9N9Jl0n76pdFc/nqI2BFCfJhd+hMrjbMMQLGqsc8=; b=1VpsuZg8LLRVUb90o3yNQvHvKhKq/roRbKG1TNnZiq0NC6CVol9aAGpArXFN69D27PvtfQ 1zcQlQK13T5NOCPdKjb6xCjS7ELNwbItBTA02ga4035nUJJCAfjZrMgU+rT8/n4y2KSimZ cgkhle+PKZaXbG5li4hUzs5eSVhfaMK5dyP5EHxsXO6iYYD7C7c4VA9TnHsaTm5sUQU/E2 Q8JXdW561XsX4jQN+98waUHVTHxdfXbC4ZNdOtONKLam+INvGgA8EAnIXrBE/6vO5Ks3W1 RS0+HzixGmRooQjjZAyQ/ZPhD2MwIB6WvR7DtVovPynLrIUvLi8uQLw5yRpF/A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738849450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JOX9N9Jl0n76pdFc/nqI2BFCfJhd+hMrjbMMQLGqsc8=; b=IgZKsIgDI8iE7RdCPOdW4PbzSFybQ/IoZVFKdF4n3qtsI+NI6KK/OgnpTK4zjKORcwqtTr tF49Z1s2GWv1K2CQ== From: Sebastian Andrzej Siewior To: Steven Rostedt Cc: Joel Fernandes , 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 , daniel.wagner@suse.com, Joseph Salisbury , broonie@gmail.com Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250206134408.lD_POjuG@linutronix.de> References: <9DA1FAE6-A008-4785-BDF9-541457E29807@joelfernandes.org> <20250204220418.35949317@gandalf.local.home> <20250205081635.397eacb0@gandalf.local.home> <20250206083039.0916ad24@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250206083039.0916ad24@gandalf.local.home> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 333BD1C006B X-Stat-Signature: bwdysysompb8rc1i5wbwyyrzi9qspc5s X-Rspam-User: X-HE-Tag: 1738849453-543052 X-HE-Meta: U2FsdGVkX1+2rEkkwYcdjesrWv4boF1TuNb2Dis3t7incdErRgqHoZsNLEXFvyF2+eo1bYSMbpjWs6jEh0k+AVByAEithWKtjeUsur/D65+dYG3QZyAbHKbuUUwe1wWDriNhUZEOXs38ZqV8u+19aJ1UqHoxfKOKJGxUgkqHbiB5dQp2iZtUCDqC9f3BwSk/LXW49jB/CVN6K0pxgfOv+QPsuooIsrSmb8igFZpdRKY5odxX6ovbY1KVFiq8QJyRwgk0mwnF69evRHY+wScRMgpEbzWtjHkqnmJ9mnYBDluDXvjJ0Zb+VZIA/HeI04S/IIDAvc9TIpkBzWJXR+ZcLnxepMB/flwgXOvABzcpic4WdNg4DdhUfs22iJRaXVIyiQIgoJUxDa4GrXN9dJsQbgZAD0YNThW5DVc+OVU0rFarka3sjTQBQVUUDA0b8LHhHGtx87wyc0+Qw/l5psxmsh5ygAuBi6a789g9cagxGiFWcl2JUI32c4PvMF0+zhoQeoWIKIP/3WV5qOWnNcWCQzauaVrGFiiDefTP7AKndfXEF/J0Qq0ksWCnzqpemiGNESipRUSO0ECN8Zs88uwlg/UHDM4K9qeMUa4BCD3GhOmXW0ub9Efknrm5boIPfVlx8+mWjf4LXXhyDjKglz7VzdXSXm9tBBrAxEaZ1DWz5Gr1Z/s4YvuNg86sPj8qeX8RYAS/6Y8DQ2FdpQ/n77e3oxYmF7oQrEbrmZTssZ+vXqoQX60ZGAZVGOEaPKv73kjzYnakzvoRD1eH1ysewDt8YaLixh0RX4OYcAXWHoLq4FePJ9hGQ+ucE4X7pm3ud6km+EXYjx+rsWLf1ozdqcvilnJUYS8L0zOKcmOcwEwR5HI1+rzx2Z38ik7XgUDsYnTD6hoU1kQYWxnP+4D7H7jmn8PSHcgVL67cjkREeJVYHraoKJvlZ3DkqYJLXh/RxPvhQYRSAikUOzyIZWLLB6R y+Gqpt9w pka8tvc2CJ0Zx6TuEkVX7SLZlJIhZ1AVT1mPQULZx6exf+hlgyWfs/s3MioljuSjfm+l1PgWt6QE/UDkaTDmXB/EhCt7Ng52mU7xItLgXAo17QjGmZsVqEghZLLO6oJts2AgAItGpC7fwc2TXQYn+636O977bTwle4MHl46LjcCaFdX2iRbkFjyg+GNng255xrWQjt7omweaE0WcclaVsLhMV6RuzcvSD432jGF6y4ali2y+SGDKoVNkl18JNcFsXFqSNxncIbkMMOIE= 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 2025-02-06 08:30:39 [-0500], Steven Rostedt wrote: > NEED_RESCHED_LAZY was introduced to remedy this. It would be set for > SCHED_OTHER tasks and NEED_RESCHED for RT tasks. If the task was holding > a sleeping spin lock, the NEED_RESCHED_LAZY would not preempt the running > task, but NEED_RESCHED would. If the SCHED_OTHER task was not holding a > sleeping spin_lock it would be preempted regardless. > > This improved the performance of SCHED_OTHER tasks in PREEMPT_RT to be as > good as what was in vanilla. > > You see, LAZY was *created* for this purpose. Of letting the scheduler know > that the running task is in a critical section and the timer tick should > not preempt a SCHED_OTHER task. This was introduced that way originally. It helped because we did not preempt lock-owner unless we had to. This isn't the case with LAZY as of today. I did add a scheduling point in rt_spin_unlock() if LAZY was set and based on few tests it was something between noise and worse. It seems that "run to completion" is better than interrupt the kernel in the middle whatever it is doing. "Don't preempt the lock owner" is already handled by LAZY with the scheduling point on return to userland. > I just wanted to extend this to SCHED_OTHER in user space too. > > > > > Yes, I have worked on RT projects before -- you would know better > > than anyone. :-D. But admittedly, I haven't got to work much with > > PREEMPT_RT systems. > > Just using RT policy to improve performance is not an RT project. I'm > talking about projects that if you miss a deadline things crash. Where the > project works very hard to make sure everything works as intended. > > I'm totally against allowing SCHED_OTHER to use any feature that can delay > an RT/DL task (unless of course it is to help those, like priority inheritance). > > There's several RT folks on this thread. I wonder if any of > them are OK with this? If you roll your own (sched_ext) then do what you want as per you sched-policy. If you use this LAZY bit as a hint from userland to kernel as "please give me up to X usec/ ticks before cutting me off" fine. It is SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of SCHED_FIFO/ RR/ DL because of this LAZY hint. > -- Steve Sebastian