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 9548BC02192 for ; Wed, 5 Feb 2025 13:16:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DAF0280005; Wed, 5 Feb 2025 08:16:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 08A6C280002; Wed, 5 Feb 2025 08:16:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4679280005; Wed, 5 Feb 2025 08:16:03 -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 C48E2280002 for ; Wed, 5 Feb 2025 08:16:03 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5903CA0ADE for ; Wed, 5 Feb 2025 13:16:03 +0000 (UTC) X-FDA: 83085939006.01.2A74E03 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf27.hostedemail.com (Postfix) with ESMTP id AB77D40005 for ; Wed, 5 Feb 2025 13:16:01 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 as permitted sender) smtp.mailfrom="SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738761361; a=rsa-sha256; cv=none; b=cq472jIkNpByVpmii+1yOrJE0knJGv2wCpknYipt/bpJlFkXh1S+Ve+0rKJGXrUJqSTmVh 3JveDDHcPfvm8U2oDH8uqtZVXaVtUakerpVVdPwNDz/PHfuIzpReEOjvf0uEYkNT39X9Ni VZw65AjOAu+5I1E/NZt00yywOvA3Hq8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 147.75.193.91 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=1738761361; 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=Coz9TlUjiS7d5EvIWdVefsMm8NzfQu707Bz/f33cz/w=; b=VF5Xm2LxVx+Fcw3GJqAt0O1WynfJ5kQc8LlRtHvBtOH+p5kvhwZxzm2HLyfMjmSFEp4+Oo fdi5j9uFiYI9QlFLjBY8UXxMxQxe0F7O7Rnna0u5cyUOQ/BG8iV26cZ2W4ash5cJZE97gy XzJrlGBqKZ6n6yGCVayssoDvCRI0FOM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E73FDA435FA; Wed, 5 Feb 2025 13:14:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 261E1C4CEE2; Wed, 5 Feb 2025 13:15:57 +0000 (UTC) Date: Wed, 5 Feb 2025 08:16:35 -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: <20250205081635.397eacb0@gandalf.local.home> In-Reply-To: References: <9DA1FAE6-A008-4785-BDF9-541457E29807@joelfernandes.org> <20250204220418.35949317@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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AB77D40005 X-Stat-Signature: sy6xh6qwbr8w6bd47k656qo55f5czks7 X-HE-Tag: 1738761361-600526 X-HE-Meta: U2FsdGVkX1/Qvzt++wnG8oPY5ie73AWjBJgFuiXN379UN0wvFh4RcrWI+iCJoGlm0UdOzHa54Iay2l6U5iA5g5aSY81k/ocxPnS+zIheaAPj60ixyEtucL10WJoj6eexeTy6x0JCxuwwL0cOBAFE84rPs+Rjt8rV8d7ihBu4vnlXWHrQQfznhNy3yL+F0nrj18GiX8fYwsdPN06msob2+KEK+Pjrycz4UfV6VF/B2dgv30AhsIcayN2sVy+VEUX6oZ2G8bgNgCNzoMTkCvRIQIjnzZSnxO4KQARAR2i9/J8lu2+TwWQy6JaL85SIxnS0RgEZfOayOFjUzXAtpJswAk2IaMS9dds3+h16cPR6r31Xd2PMisu13S+CBPukb/Da6jG9etdDi61KRy8xnwMSpin/ov3rFAlsf8qMw+1P8PYJH8Y9UrxF586j9zGzSEnMA39m4u+AsQNBxn4yHhIvQZsRoJFe6u6ELKVuZCvA7oZ5PwhwF7nCUXu0OzC3Of49hnzd4PKZuSTcYuP5Um7Eu9jMmAEqpdyFEVf1mi2bnxJGYb2ax8h4/xS00WiFhrAwwopiAGYrPB2HWJJ6FU7mCzTtDmnrAf0xQ30l5B4VPVFpY4ZPkL8XXNg/EaARuzUzmkN9wEajERxmIuQEyN+2D7Dvkvxpd947JJxA70XRCZlPZze/8j0KUlgJ1o1V+5tReDchUW3tjJPrH6hN6bmuRZCRoKvWK3rwRKNhP8TLfiG8fp+mk5gCUIKSDcamw8QmFkuKsH6CIzSUFi7NxS/B4v/JAv1H4sY+ftPr1NPUies7lqbImrTixdzPytR+kALUWcvtJlBhp2K4YPHzmt2BKRpRoWCwlEoTgwPmHIwr0igSAVV7NrjzqFChKPRWgccIXBQxu2exjDg0g1eQAFtR4Rjm/IF7IgZKx5JB4xd6ueWrqNr/pNIMrwTJ45w8Fu21Aw+xWy6W9FRLJiLVJnd ww5Pdj3o +j21SHoM6sG2tIMiad5GAZoxSLWv+jXLq7yocy+PwmmB2wYNixSnTLqzqmg4tJ15HdfB1hofcMUzN7Bavro2f8vqlYcCCAhUEvfWV9KTN0znBkuDj7xe19bTvEY4zHtpA28lnpoZPdIUxRDWl+CU4f+R0fBsmFO9m3AJ0YFqmUgmBYbzPvIa866qNc9CQquVxicw//qZzfH5Ckdb0OXmmEt0POBsqt3tPxc7NvDT+sgd5dNZ1lh1bGqoFT52D9ldHxfFc6MtuzU/aEGN+knteJ8/Y2T93iR7cOrscb3MsIaAkx3be3Ox+8vUQg1zjbKTIDmQC4DDU0K4aWGxWfdhO2m0/4pSCTEeFRM5YLBCMnooE+6jZ8NCSSkEUPxaIT+EvEywu251dIAu+rGFL3SVmcLt4bpvPxaf9t4a3iC0CuHylqwbvNT1FpKDF6w== 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 00:09:51 -0500 Joel Fernandes wrote: > On Tue, Feb 4, 2025 at 10:03=E2=80=AFPM Steven Rostedt wrote: > > > > On Tue, 4 Feb 2025 19:56:09 -0500 > > Joel Fernandes wrote: > > =20 > > > > Here is the RFC I had sent that Peter is referring =20 > > > > > > FWIW, I second the idea of a new syscall for this than (ab)using rseq > > > and also independence from preemption method. I agree that something > > > generic is better than relying on preemption method. =20 > > > > So you are for adding another user/kernel memory mapped section? =20 >=20 > I don't personally mind that. I'm glad you don't personally mind it. Are you going to help maintain another memory mapped section? >=20 > > And you are also OK with allowing any task to make an RT task wait long= er? > > > > Putting my RT hat back on, I would definitely disable that on any system > > that requires RT. =20 >=20 > Just so I understand, you are basically saying that you want this > feature only for FAIR tasks, and allowing RT tasks to extend time > slice might actually hurt the latency of (other) RT tasks on the > system right? This assumes PREEMPT_RT because the latency is 50us > right? RT tasks don't have a time slice. They are affected by events. An external interrupt coming in, or a timer going off that states something is happening. Perhaps we could use this for SCHED_RR or maybe even SCHED_DEADLINE, as those do have time slices. But if it does get used, it should only be used when the task being scheduled is the same SCHED_RR priority, or if SCHED_DEADLINE will not fail its guarantees. >=20 > But in a poorly designed system, if you have RT tasks at higher > priority that preempt things lower in RT, that would already cause > latency anyway. Similarly, I would also consider any PREEMPT_RT system And that would be a poorly designed system, and not the problem of the kernel. > that (mis)uses this API in an RT task as also a poorly designed > system. I think PREEMPT_RT systems generally require careful design > anyway. So the fact that a system is poorly designed and thus causes > latency is not the kernel's problem IMO. 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. >=20 > In any case, if you want this to only work on FAIR tasks and not RT > tasks, why is that only possible to do with rseq() + LAZY preemption > and not Prakash's new API + all preemption modes? >=20 > Also you can just ignore RT tasks (not that I'm saying that's a good > idea but..) in taskshrd_delay_resched() in that patch if you ever > wanted to do that. >=20 > I just feel the RT latency thing is a non-issue AFAICS. Have you worked on any RT projects before? -- Steve