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 E9FD7C02196 for ; Tue, 4 Feb 2025 12:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 810996B0089; Tue, 4 Feb 2025 07:50:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 79AE76B008A; Tue, 4 Feb 2025 07:50:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 639836B008C; Tue, 4 Feb 2025 07:50:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 427F36B0089 for ; Tue, 4 Feb 2025 07:50:46 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4B1BA140AF0 for ; Tue, 4 Feb 2025 12:50:32 +0000 (UTC) X-FDA: 83082245946.18.6398192 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 926EB40009 for ; Tue, 4 Feb 2025 12:50:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf12.hostedemail.com: domain of "SRS0=0UFz=U3=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=0UFz=U3=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738673430; a=rsa-sha256; cv=none; b=xVHN81fmGflhgWQDdeajCcbOWZdGJfLH2gwf1nZotlpZATXR5b9ICiCvH8cLr3iEpuuL0u i4y/ShPH7dB/LMWy7h5I2+5XzFIYkoaVYd+oC2S4+Jsa1YLq71/u3Wx/EMwaSAV3O3DGnL pGxmO3E3XsHgV6IPdRaiW3WfaZ4Skow= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf12.hostedemail.com: domain of "SRS0=0UFz=U3=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=0UFz=U3=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738673430; 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=kEn84lUpwQ2sM8RUU1afIqITX1GBhD6zBxlGKCqo2nw=; b=6dvZevc9noatpHQETV1mZ7U9IvMSGBZv9Po7vb+hLJwAQK0gfymvjCEJ9jpd1UDvAjIPvy TGv024f3Q3TLvaEr4jWZ/VGSelHJ3bpixKz9doeN9ZThxx7W6anqryFRn8wRcDGauQ4SqM TDz4gdpm0C6kTWPQkuO8ugM8MgTwNrE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 90E505C6256; Tue, 4 Feb 2025 12:49:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20619C4CEDF; Tue, 4 Feb 2025 12:50:25 +0000 (UTC) Date: Tue, 4 Feb 2025 07:51:00 -0500 From: Steven Rostedt To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Thomas Gleixner , Ankur Arora , Linus Torvalds , linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, 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@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Mathieu Desnoyers , Clark Williams , bigeasy@linutronix.de, daniel.wagner@suse.com, joseph.salisbury@oracle.com, broonie@gmail.com Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250204075100.3fcbfda8@gandalf.local.home> In-Reply-To: <20250204091613.GQ7145@noisy.programming.kicks-ass.net> References: <20250131225837.972218232@goodmis.org> <20250131225942.365475324@goodmis.org> <20250201115906.GB8256@noisy.programming.kicks-ass.net> <20250201181129.GA34937@noisy.programming.kicks-ass.net> <20250201180617.491ce087@batman.local.home> <20250203084306.GC505@noisy.programming.kicks-ass.net> <20250203114537.6a30c7c0@gandalf.local.home> <20250204091613.GQ7145@noisy.programming.kicks-ass.net> 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: 926EB40009 X-Rspamd-Server: rspam10 X-Stat-Signature: ta5d4ujr5ug7s5gdhuhewhwh4txamkqf X-HE-Tag: 1738673430-125430 X-HE-Meta: U2FsdGVkX18+QbykOaJ2YNQZN70Jc014lTvU50lxGKIO3khq92PcrJ2IBYZcjiMcUm9MsqmpZjXmQJ3CDSyiQDw8+035G3APMMxlpCJENR2EnTq/FrcKhwmPiTY0AHR1sJJr/Lt5/ccansUZwpnKLeExbuF/e54b41C5QbO9io/VhKd6kmQapM4rXt/HD7Td1kWXElz2ytgcl0xbv4x4baUwfXkhBxXUIdgjUy+6faX4vXFwKD615HfjHz7zfSkcmcAC8UJVawVFHSVO96p0ZzYgCG0FDNC1ylBHrw3+lEwTwuc76zIii8uSjjBt1CyDWT2lXILTYkMQtIo0+vd0oBeV7L0kBN9xbFIvrHINHXW6QYUYWbLUdwP6TB0mMoisYcLNdGIsfBF30XrtAaJjbWzN/0SPbwVYTrEJuHM3Iy4pzmHy4VKp3FC1mveyVYgH44vSm9PvajiXE2oJmiJixkpz6LcO1sjff9S6gcYPLPenjeEe+M1q8eOGXTfgqINMEYIRrWEA7FPfvdLxizJxstkRGASwJZ71xmUc9UsMDw/LRA/pYow4A/9ZMMNRj07gCXtGVcXRwZvpt6e7nGPPJd44m/Kym+AuztLxHohh8RxfaaHJ0nubn3fNAG9smsBkwK9whPZEVRgOxl5xA89/xmOshSGlMCK+hRsW1j780Qpto/i7m7BiHTRVPkLbwUbFLFE6mzWZR0h+eDWAxDZD7OawVRJWiEMX0C8HikJIwNMgkIZV7Ot6qwuQ4v10NVUR/gUo8oZ/NsxOlFHT6ySZLD0Pir1oDJLSttmGYXcGnPz8bxrEeP9IAr2SAeWf5jQwCLIobwnl9QDEC7QyUmBl55ryOTWblaVMX/dCLgczmGFwZoJn3d+zDLrmV9LbRm9BPCxrNizuhrEWWvqK/wQBsN2xszq4vvH5wDLo8Fn6bmfwjEPLLk5t4x4KrqhaCKujSxPAHcOvEEGBYtdnwem 1HJDDz7L 3uEX9i4dH9rCiau8RxThpIF0T9lrca7TQ8KGAbYPYA64iN6lQVJALMiTBhhnfVXkAOpJymlYIxhhYqrZSjyjDLgcCBl5djkRsJVs8uCdC2edcu26I4TynJ83S9X+YIQM37NwSDru8wRHhDjgCislh8XTMi2OOVxGzS+Unpj58AmNnx2Drpu5R7zEQD2xxkrkspJ0iclbhYZw1mPZRMdyGoHsxjuMYFTluyZ4h6RxSXaeuPbWEO+VkNN/msDlDnLUSN73wkc4EtyW5LSppvJ2C8OeSRe/bKF5AIwzgeYpu83kG0kp5ZBiSZ+IL2/n9OFmov7x2Ol01ogoui4WTChaiC02VRJpHklv7r0NmNZ+XaqNCZBtFYVA0GtVLo6v5BlEAukEP 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 Tue, 4 Feb 2025 10:16:13 +0100 Peter Zijlstra wrote: > And yes, you can still use the whole 'delay preemption' hint for RT > tasks just fine. Spinlocks isn't the only thing. It can be used to make > any RSEQ section more likely to succeed. > > > > Patch 2 changes that to do what you wrote the last time. It has a max wait > > time of 50us. > > I'm so confused, WTF do you then need the lazy crap? > > You're making things needlessly complicated again. Do we really want to delay an RT task by 50us? That will cause a lot more regressions. This is a performance feature not a latency one. RT tasks are about limiting latency and will sacrifice performance to do so. PREEMPT_RT has great minimal latency at the expense of performance. We try to improve performance but never at the sacrifice of latency. RT wakeups are also more predictable. That is, they happen when an event comes in or a timer expires and when an RT task wakes up it is to run ASAP to handle some event. This is about SCHED_OTHER tasks where the scheduler decides when a task gets to run and will preempt it when its quota is over. The task has no idea when that will happen. This is about giving the kernel a hint that it's a bad time to interrupt the task and if it can just wait another 50us or less, then it would be fine to schedule. SCHED_OTHER tasks never have latency requirements less than a millisecond. And SCHED_OTHER tasks are effected by other SCHED_OTHER tasks, even those that are lower priority. My patches here were based on where the NEED_RESCHED_LAZY came from, and that was from the PREEMPT_RT patch. The problem was that the kernel would allow preemption almost everywhere. This was great for RT tasks, but non RT tasks suffered performance issues. That's because of the timer tick going off while a SCHED_OTHER task was holding a spin_lock converted into a mutex and it would be scheduled out while holding that sleeping spin_lock. This increased the amount of contention on that spin_lock, and that affected performance. The fix was to introduce NEED_RESCHED_LAZY which would not have the SCHED_OTHER task preempt while holding a sleeping spin_lock. This put back the performance close to non PREEMPT_RT. This work I'm doing is based on that. It doesn't make sense to delay RT tasks for a performance improvement. -- Steve