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 B9752C02198 for ; Thu, 6 Feb 2025 15:02:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 209C8280002; Thu, 6 Feb 2025 10:02:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B93E280001; Thu, 6 Feb 2025 10:02:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0811A280002; Thu, 6 Feb 2025 10:02:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D9CFF280001 for ; Thu, 6 Feb 2025 10:02:46 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4BDA31A1175 for ; Thu, 6 Feb 2025 15:02:46 +0000 (UTC) X-FDA: 83089836732.28.42645D7 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf10.hostedemail.com (Postfix) with ESMTP id D195DC0068 for ; Thu, 6 Feb 2025 15:01:58 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=WnqkPlDd; dkim=pass header.d=linutronix.de header.s=2020e header.b=XMYuKqcg; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf10.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738854119; a=rsa-sha256; cv=none; b=gSrTQDaEMCErZTX9M6zCg4kvhbNlyoFswz8C4i+b1ILAZeUZXLgbR10rYezjzUXeiNrm6P 3yvTBqyNO+4jHfBfkPkBOfJqEBkJMaIUb2bkxs3zTXZ/BHHrV64D2O9kXBU1vLozp5stM8 33tQ2yIep6ASVWCZYZUfIBUzI3fVEEo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=WnqkPlDd; dkim=pass header.d=linutronix.de header.s=2020e header.b=XMYuKqcg; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf10.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738854119; 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:dkim-signature; bh=C5we7CRCJYf2T2cXW5xWDkSUwqZKvYZDnh+kkqACzH4=; b=ZqSqFcw2+eDjPKuWZPRRxKnoU/EPSpzxQ/I4H1XEvllCqcc86M5trfa1GxlOQp4xXcowna NCNftNFsmc7ZdeVh7tFC96o7p2vHKpumuFhB1VzEHUWDntSqWDb/XJAFTRqZWseOnlfa1V DT53cagkBBGhCLaXNFBU/gdAK5FpUbo= Date: Thu, 6 Feb 2025 16:01:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738854114; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C5we7CRCJYf2T2cXW5xWDkSUwqZKvYZDnh+kkqACzH4=; b=WnqkPlDddQRrl/XcuWgQ/VRu658eVuS3UVGJqoeadcyglAswOtlV6AFprqFA/cNNUi0TWU oIUn+c0sAewYOoDoFS15Bz5g2YH5abNebG8xMlQdWq7nTUI4eqiwFNT5aWVoZTQfs9gjax RSrDx1+/stHyVygesSBRXnxIeP1g/1cUILn9M2P0Bsi47+kfzHjIQvLpiLuSoqcp8wRu00 oSeQhvp+AK72musR71bAsoEOyMVqUUXiSoiEp1tD5R6+4Pd1CrpRH2PWD7tgl24/fagTue 4x3kjHqsKHrYec0h8lXZFzumhpILpWpFxnBvNj0ivFxWrpkk/FD1LnVQZaKzlQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738854114; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C5we7CRCJYf2T2cXW5xWDkSUwqZKvYZDnh+kkqACzH4=; b=XMYuKqcgF0VIaIxYp9mnlOO4guMNYbWXyWJdZvYXzv+QYRkS5Ov+IPzonT9WICuo2W1qm4 ZPWI+RhxqMvk1rBQ== From: Sebastian Andrzej Siewior To: Peter Zijlstra Cc: Steven Rostedt , Joel Fernandes , Prakash Sangappa , 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: <20250206150152.-5Fauhtm@linutronix.de> References: <20250205081635.397eacb0@gandalf.local.home> <20250206083039.0916ad24@gandalf.local.home> <20250206134408.lD_POjuG@linutronix.de> <20250206134859.GP7145@noisy.programming.kicks-ass.net> <20250206135353.i1tp4vDv@linutronix.de> <20250206135744.GQ7145@noisy.programming.kicks-ass.net> <20250206142234.-kcSg0xr@linutronix.de> <20250206142717.GS7145@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20250206142717.GS7145@noisy.programming.kicks-ass.net> X-Rspam-User: X-Rspamd-Queue-Id: D195DC0068 X-Rspamd-Server: rspam12 X-Stat-Signature: c6x8kxgk3g4yhsh763d7fx3rxo6f1d3p X-HE-Tag: 1738854118-378109 X-HE-Meta: U2FsdGVkX185i5YCrtypKySz7dg42wb7MgFG61UQzC4376IoBPQjXR5oeS7GgYUs3gx3MIHtnyhV2AgMxC095bEz/EIcOiHlerQf8DTdyv9M8A/ml+BwUfd8QhE3Se6zQlLOXCh52L5XZkk6PbVHn+dxane9YR06Hn3hrDxzUZHJdJMYOOtI4qtK+5FMJVzYSjIClbcaJvQL1of5NKMW6ys+Mb4Xt3yM9DQWpy8GTY6c4hYXrEFmawtP+p4GpmtptRNvfw8CREFpGro2WX+xb2dnpxT+rXGQAaFofbnYoryIf5D68a/CfnjZWbxnJ7oAun7NnXknPqH/143BGWTDnblzvsLH0m3FdRevrN2cW02mN6b1Yt33DyH3nBqma9wH1lF7NAbX1NIzxayuP+noC/vtroEtiPEKzO/tGlaLHEo15ofGQ74OkwkvyjdqBdztr+uYRMOhuk3N13LMuQU3Wwstd9HH5Bj26vTGRsYsT5PwltXo42BsT4r3aUynXesQSxoNg7ccmqYghNvBxRjB1zFswLkPyz2uCv+Mb7hL6Ymgge9sHk41w4s2lBJnxADIihnfGAvDxdlY/J58lnBI2e6ih//HiXcx3P20sZY/hEBJQ7Y6lU/3rHFHITlqLZixuorya1O5n6wZV/pAsN+hxobNzMI7MJltxhc9IJ/3ixFrJnI6BQNHI3TXHl1BVc2vjHqyzSCjnGS7ShWluN+mNsXuPDTr03RZdksbYUhcXJ6YMi+vCTLRBRxfWLtf/cyp3qnM5usKOMSTb7poRuPFcfQ399eOw9Z6OxkT/X0CeSP5BCWsirOOSrb9fPN68pLIYPhZqiWEB7Nk3OD4sXIg9+cUV7vsicdkM+iPM1JmVG1PK+xqIX8X0MDxJnUkQ2IlotJgVXNOV16saoqAl9o8Rxry0lRT2HccDQtHpWDbUtwXwDKgxmI8cmBSxEoghnpotYuxlAWdWU3piciZ2AL mOrPzcKz FzK2gUDkAWTncyjg0xEtEbih308a+uGc9slXL1yLU7MyhRM7al+4ePriHSShuhvdGZa5dCNlcJ0DgBuYqhX+hmh57ztcmjIUdjnUewEzz6kEAtR3HTPDCPvLORw7MzLG9HQkHV9bvKkng2OAxLNEBbeqY/cDIsBD2bbwaBixM0DApeDHgCzhpLnCvQ2+oxJO3GsnYbyFuPc/SIoGIvbqJPljKjcn/+sIduglUTDz6L7vwnLlWOP2YUhtlj/4yXYhl8+NqnTEQMEcQjGo= 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 15:27:17 [+0100], Peter Zijlstra wrote: > On Thu, Feb 06, 2025 at 03:22:34PM +0100, Sebastian Andrzej Siewior wrote: > > Then this feature adds 20us on top? >=20 > The point has always been for the number to be < the observable > scheduling latency. >=20 > I'm not sure what that number is, and it is always hardware dependent. I > measured it on a random test box when I did the prototype a long while > ago, and ended up at 50us, but for all I know that machine was running a > lockdep enabled kernel at the time (won't be the first and certainly > won't be the last time I try and do a performance measurement on a debug > kernel). When I have lockdep enabled, I have scheduling latencies >1ms. > That was not the important part -- but everybody fixates on the number, > instead of the intent. I don't mind to delay a SCHED_OTHER wakeup for the greater good. And here a number, 50us, be it. This is certainly not something I complain. I'm just asking not to delayed the wakeup of the RT task which should be on CPU based on its priority. Depending on RT application, it is not just the interrupt and preempt-off section that you worry about. It could also involve to PI a SCHED_OTHER task on a different CPU to release the lock in question so that the RT application on _this_ CPU can make progress. So you have 50us on the this CPU and 50us on the remote CPU because it also does LAZY thingy for performance reasons. And so the number doubled. > I'm assuming you have a recent number around -- what's sane? 5us, less? As I tried to explain any additional delay hurts. If your application requires a latency of 1ms, you get max 100us based on testing then additional 50us certainly won't hurt you. However if you require 200us max, you already struggle with 160us especially if everything fires at once and the caches are gone. In this the 5us will still fit the requirement on paper but the buffer got smaller. Also, the 5us requires a timer to fire etc=E2=80=A6 There are "bigger" x86 boxes with high clocked CPU and big caches which can be partitioned and so on and everything is nice. There are also smaller x86 boxes where you have two trace_printk() after each other in an IRQ-off region 2us apart and yell at the scheduler for taking 30us for a scheduling decision. Sebastian