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 F18FCC02194 for ; Thu, 6 Feb 2025 14:22:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82B73280004; Thu, 6 Feb 2025 09:22:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DAD7280001; Thu, 6 Feb 2025 09:22:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67AD0280004; Thu, 6 Feb 2025 09:22:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 48D92280001 for ; Thu, 6 Feb 2025 09:22:47 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E14D7C13AC for ; Thu, 6 Feb 2025 14:22:46 +0000 (UTC) X-FDA: 83089735932.06.0747542 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf12.hostedemail.com (Postfix) with ESMTP id E41CE400AE for ; Thu, 6 Feb 2025 14:22:44 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="zi5eh1B/"; dkim=pass header.d=linutronix.de header.s=2020e header.b=QMI2yJw2; spf=pass (imf12.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=1738851765; 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=/GZ0eW3ydhChOWf2KoO0stzIjEJNWi+XUy5NFjSLt4Q=; b=Xx9iVM7IVwumXfspav7tQzduSZ5sWXTpH2Do7jLU93q0lcVxvK00IfhmWClc/yvvK9xanp u+LILgANYnFMZjd0vEPguinJZ2OxcPtJzQ2SGeO+YjJSh/rLOIK3N87Hd/ZaVvO6axArk3 QznEO0inVr0SMfnykUGoPQzPBfA8JsM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="zi5eh1B/"; dkim=pass header.d=linutronix.de header.s=2020e header.b=QMI2yJw2; spf=pass (imf12.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=1738851765; a=rsa-sha256; cv=none; b=eXqmyzY1QgIk9KtCIU3vCEfZoHMbrS5M7irHNiHI0kNw/Bv2N68C90qXDQzFWinsGpwd2d yiyivTV2e6oL5J5JiXY+epeOMoYRGS2aXPm63DxZEKiT8gfC6a+xrW83rGFSTKIfzKpppR pbiVBEm7FX06z9wYC8EQW5K9f0mQy7Y= Date: Thu, 6 Feb 2025 15:22:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738851756; 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=/GZ0eW3ydhChOWf2KoO0stzIjEJNWi+XUy5NFjSLt4Q=; b=zi5eh1B/VgIhag2+mS2V58qg96ULzdik12zgp3j8dOlt6fSvQLG+VIo2b3WW6lzxuwlKtP T6GCFUrIsKEW4PFa/n9dX5cP87vwjnKxnOvVgxoqA6TTCBJjyladBCQC8hTAgDHKJkauvE XgnP/6FAaMl5xRxCnmMlUDZarAMVUQ4PetGJJUvVFhcgKyvheKKrIijp07PirsfrVpRWhO 4i0Gf3BSnrNPA6geu2ZSB7m6iYLSvsy4g44wtDABn62BR+NRhREMEMv99cwdkFCJTOnn4A dp9+KtCDzvhuIkjyjXQkHz3/OM8G4zE+m1TTApNIUDH6ppb16To8VDKfD0gSNg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738851756; 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=/GZ0eW3ydhChOWf2KoO0stzIjEJNWi+XUy5NFjSLt4Q=; b=QMI2yJw2GyINqfZEYUCNRybW6orTAhTQPXCGAfKk1EOA+92G0S40wkoeFJ8DuqsDqv1a2u /R29RuTIMfWrpMBw== 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: <20250206142234.-kcSg0xr@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> <20250206134408.lD_POjuG@linutronix.de> <20250206134859.GP7145@noisy.programming.kicks-ass.net> <20250206135353.i1tp4vDv@linutronix.de> <20250206135744.GQ7145@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250206135744.GQ7145@noisy.programming.kicks-ass.net> X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E41CE400AE X-Stat-Signature: ds3foooxw4dsgekj197c8du96tq7cxfp X-HE-Tag: 1738851764-19887 X-HE-Meta: U2FsdGVkX1+yXBya0wBQHCufF362T9Y/feoiFk85ESorrTV5JqMPvstwL2NMwWy9RvpVawHV7xShadCFPdk6SuHKsQ5l2yDtBFAyHfkAMIENIWEr89E/vyWmKZG8fC8HpKcW9PaKZVi36GpkwKiuMrXLLfaY6HE5Zze89yho7z0eTaTMz53WfEtecvkOzTQKIqK0CR+30vnI9GYFu9tT3DUGKnlMwyZXa63wZn+FSGSM0gr6A3A36k9ka0qgSg8ii94S2d7q+OIZbI716W/dT7kn4yhuuhoMOzITB0M4Qobq02MeuQ2nBIeBcFVILed6XDV5H7M02kVs6PWotXdftjsnOEhkCt49V0P+Z6xDX2kJNiOIVludECXXKwFfe4W8U2S+JMJrWTvcI51Ri2C9AEQQ8yf+axDUil0U6Zk2ZAcywc0x0ldtPlmk1d4cpw94A7jbESe5WW0k21nRmj/8MWOnjCD0fGTS5XnQoqjGtbhTy7p84xW7L0yOGcljquu0hLuL0o4xGMSuXP6bmMzzj39KdIFk2ia2kb6TAi6G7fbdaCIiEDHpYAWGRvlw1fjWg6WSwlUwdDMnXf4j7kOb+cnT//nff9LeTLEZ7lw3FcGp+nFyBF5Rpt9b99vqXpweNhXwz8OJQuVQ7bDzqSIJK6IZFFzpdU7EtCMz2kS9QgFoDBsSRRoN81U3YlJHrr6ldA4cOsDiTUvggnHziC4PQ0+YI0JLB5aggbqvKsPqpn/0LZZq5Pxw7XZCAZKFAdszgAlqJsYHvRyWhcw47JqcWJVvvNgUuHQ7CV4OuYf01BffENBJUY/ZaWPBozueQNND8Jn+2ETbcaXTTdpafN6zDncXHrHVY1dlur6YR9ueYkdALcSHY5GhM9PU7dCpeTm3Zlnd8EG1sZC3FWnp9I0yTQoQsTU5RYmmkpd48jcsScPkoFT9r3NwJAVc/5YKJZeWrUTZ/gsvPOBdzbYOhpG fQD2aS3y ZU9qmadEi24VIdmBPHpDBLZRSltpbnEtZ6luyA0z74A5dIjNtEDxIDuWzwTqNmZ+3f3JSfO+447xZHL8tR/uORYgvsMBCOkJw485SdD1WBclCnMeMwlC52GqJeZryOPNui3r0brqWQEXIZgImUQpO4Gz+FiF0J3YY57avqFZyRTPqeMgpgctKnEPQe4B2+OMSINb9Bs0iWl1oEal861wBnTU7Ss8PWYpWCz+Jk6fxv80prZuYTSJz1sZHzWaK5pMtzyLd5TKRZWn73+8= 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 14:57:44 [+0100], Peter Zijlstra wrote: > On Thu, Feb 06, 2025 at 02:53:53PM +0100, Sebastian Andrzej Siewior wrote: > > On 2025-02-06 14:48:59 [+0100], Peter Zijlstra wrote: > > > On Thu, Feb 06, 2025 at 02:44:08PM +0100, Sebastian Andrzej Siewior wrote: > > > > SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of > > > > SCHED_FIFO/ RR/ DL because of this LAZY hint. > > > > > > Thing will get delayed if interrupts are disabled or kernel has > > > preemption disabled too. So as long as we ensure hint crap is of equal > > > order, nothing cares if you do. > > > > > > If you can't tell the difference between task does hint crap in > > > userspace and task is in the middle of syscall, you can't tell the > > > difference. > > > > I can tell the difference if I see a trace where an interrupt fires, > > performs a wakeup and the SCHED_OTHER task remains on CPU while the task > > SCHED_FIFO task sits on the runqueue until a timer fires. > > Right, but so what? Same delay will happen if interrupt fires in the > middle of a preempt_disable() region. But I do see an interrupt and a wakeup in the middle of a preempt-disable section based on the preempt-counter. Then once the preempt-disabled section is done, sched-switch is expected. > Or if interrupt gets pending while interrupts are disabled, except your > trace will not show that. That is true. In general we try not to have a lot of these. Also pushing the "unexpected" part of the CPU such as unrelated interrupts. So may end up a RT thread and SCHED_OTHER threads on the same CPU. It would be very unfortunate if this "let me give a bit extra time so I get out of my critical section" within this SCHED_OTHER application affects the RT application. You run SCHED_OTHER tasks and a cyclic interrupt wakes your RT task every ms. You expect to be scheduled asap, so ideally 0us but 70us in real world. Then this feature adds 20us on top? > Your worst case response time isn't affected. That's all that matters. Sebastian