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 936C9C02192 for ; Wed, 5 Feb 2025 13:44:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 027D0280004; Wed, 5 Feb 2025 08:44:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1A77280003; Wed, 5 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 DE26D280004; Wed, 5 Feb 2025 08:44:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C0067280003 for ; Wed, 5 Feb 2025 08:44:16 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7D4461A0CA6 for ; Wed, 5 Feb 2025 13:44:16 +0000 (UTC) X-FDA: 83086010112.06.4D2BFC5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id D5E95140009 for ; Wed, 5 Feb 2025 13:44:14 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738763055; a=rsa-sha256; cv=none; b=n3riBwagsjYqoSxRsDGzayJVr8C3b9rXNm8QqQXyuqPEaiuH01VnfVbJeAI2F/Ks5jVIq+ e2XrkL+3DD+IPf+P89PCSIFHIpiaSFbN/6jvEW6xu7dvR28btI7V4RRRo0qR0mn+xZAsLF 0lettMqS8C0pYP4ij0HIjdxUwqLzWiU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of "SRS0=k7rl=U4=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 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=1738763055; 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=3g83bnzgsxtXQkjKK1kx5TFvyExuTLPqtitlYDxf2Cc=; b=Uibyya+9b5aykkVDkWUudoMW41pgo+Gse18SOs4qN2sPJF3QK0uUKvC0bsb7o/4scNGyzy ygfVEBAXJPIlUKn6TgAwnRpCIz3sY5G4KQri7ppNwgEuFr29ZOKw445Vd1b2yv9/KKm1ze Afv25qQnL3bj04yxElty4hHGXSLRS/c= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 16D785C4B56; Wed, 5 Feb 2025 13:43:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2165AC4CED1; Wed, 5 Feb 2025 13:44:10 +0000 (UTC) Date: Wed, 5 Feb 2025 08:44:49 -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: <20250205084449.1bca619d@gandalf.local.home> In-Reply-To: <20250205081019.6f81f05a@gandalf.local.home> References: <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> <20250204075100.3fcbfda8@gandalf.local.home> <20250204153053.GX7145@noisy.programming.kicks-ass.net> <20250204111119.10ee37c8@gandalf.local.home> <20250205090736.GY7145@noisy.programming.kicks-ass.net> <20250205081019.6f81f05a@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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D5E95140009 X-Stat-Signature: 5gwrj3cujanaxm8awpn7ab6zkin1ps56 X-HE-Tag: 1738763054-400639 X-HE-Meta: U2FsdGVkX19CbJlXSOuKqCO3Xdygbxy5yvEUF6mY0oEN+KqZRk5H7mt0zNJQuXkK7o6yRbIf5PRf+wkWrVu91f0MBopofTOL64ToqNz0nqoHlnNJBNoCHqeS8P0Hj81aBHg/z2sp2blhlxeryNkBTf/8zndTFFiSD3Pfme/0Jlr7nM3m6t94HBehxykOGB1Wie7sp/8kArdHg1VEkuDn+YDZ6aeWM1HpZpU4AzbfozQmKv4jqJm8VvGD7C+iOfRNyv6STEYMKJ+59EM9/5rp4Nq0bdW69C7KSmjv+6rslBo1661UpaYhT7NfSqqgG1JMx1lSnEveRVIpIEWSlr7YrRitLaEhEewll3l/8qq4u/92Xlw2JyNoQzxezpsmCrQgfVkjS+z4ur4zxuEmn6fPcPDSeCbNg6P0w6QMT+/x1Qvdk2lgl1ow+Q/Yqy2EjBzjXi8WluKCoQYvVRecU4xKsJ6Wbe3Dfsffy1hhGtM1445pb8GY9E9hcW6AkX43f9e5FnP3dRC8GU+qoPvWkPmmOS6j1HL2zqkCJQHD9z2rSc3LYeMtJENmRUzaK+Wh5FNsx/f4eZaBKDNxSCLI6QYFMGvnPB/ActEjmgRfey+dPCiZRkbkngj57EkgCVeL2rp1eSsJjjwYr70WEyqDPK2KQRRgVAalf2Vyqm+WkLr4YoP+YnaZIQ8gGOjeckCuHCD7s4ITe1q3UkP09vdObqlvLtbriP1Rtd1K18RPqo+LuwLtAeIOwiB5UkBCBeGNn74mYiw26uRgizW7dwssx7mioTg74o+y90TdCdmmj+nb+aULhBY8h+nh1cQSyGVPaTt7/i5N5SkyohNFLQcbxuNDjktjYMQgxSg4M4mtQ6TZMeSTO4aGZ6LUZ3fev+R3UyJ+ogU0kLauzVipuSpqKuUPt/6glZep+8bpCHSQFKTkO/aLXHkPZoV/DRmCiNZqdQz6lpHpZ92q9QKWeX6o2B0 w86x5ftI 8+CND3vbalGB7RLMuNqIprPNsLMO+JUc+/4HW2+T8WQGugMI/dEc/6ktYHRObuSJpjFsDLlb/5fEAdVrMNlQ8RC9lqr5p2kRNfmc2II4Au11DWCFuka9dvEatw/ONWHorIPrQ5mYlKYtGQ31IR+M0AG0rzryDrD5dRgXPQhT61yVrSSQF9Atui8RHSzF42+RcljZA5mfGC9MpZa5i8ElRC/CnfwxJmE+U5ry0MVl67UjHYxAjYePc4k3XtKXurlRIsn/dkz4ImC64gqPJAOXg0MCA0vnqnbra7kL8tjREt40AxLL/OtUQdCGLVdJuGRHcGrIPfnCRD5dhzvd3sqD+XthlN4Du61aEPcomxx14Cwb3RaXChgQxhSuZ40+iPMhnMWXUzV3G88Wb5+TlB3m78N5qNQ== 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 08:10:19 -0500 Steven Rostedt wrote: > The preemption method will influence that decision, but user space doesn't > need to be know. If your issue is that this depends on the preemption method, I have a slight change to make it work for all preemption methods. I just replied to Joel about this: https://lore.kernel.org/all/20250205083857.3cc06aa7@gandalf.local.home/ I'll repeat some of it here. Currently we have: TYPE | Sched Tick | RT Wakeup | ===========+=======================+======================+ None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY | -----------+-----------------------+----------------------+ Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------+----------------------+ Full | NEED_RESCHED | NEED_RESCHED | -----------+-----------------------+----------------------+ Now, if we set NEED_RESCHED_LAZY in PREEMPT_FULL (and PREEMPT_RT) on a scheduler tick if it interrupted user space (not the kernel) then we have this: TYPE | Sched Tick | RT Wakeup | ===========+===================================+======================+ None | NEED_RESCHED_LAZY | NEED_RESCHED_LAZY | -----------+-----------------------------------+----------------------+ Voluntary | NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------------------+----------------------+ Full | NEED_RESCHED or NEED_RESCHED_LAZY | NEED_RESCHED | -----------+-----------------------------------+----------------------+ Then going back to user space from the interrupt, we can use rseq and the LAZY bit to know if we should extend the tick or not! Even without rseq, this would behave the same as NEED_RESCHED_LAZY will schedule just like NEED_RESCHED when going back to user space. This will allow this schedule tick extension to work in all the preemption methods. Would this be something you are more OK with? I can go and test this out. -- Steve