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 AB099C0218F for ; Sat, 1 Feb 2025 23:08:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 406236B007B; Sat, 1 Feb 2025 18:08:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 38F286B0083; Sat, 1 Feb 2025 18:08:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 230116B0085; Sat, 1 Feb 2025 18:08:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0393B6B007B for ; Sat, 1 Feb 2025 18:08:16 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 85C271A1286 for ; Sat, 1 Feb 2025 23:08:16 +0000 (UTC) X-FDA: 83072916192.22.776721F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id E2D78C0007 for ; Sat, 1 Feb 2025 23:08:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of "SRS0=QCtu=UY=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=QCtu=UY=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738451295; 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=UyGdCm+oDzvato4vDVBDEasgDglqZwC/FEbUqtCRuu0=; b=D/h8E/dsFyOlCtcZ+Co86suM53c5kAFXU7Ht1eMU7agid5pUlaCPUvNe9t0LbzhjLR5oH2 C1xGqouOqyyOVoqmWuRe7od3OeSjj4n5EmaQzVVh1GB28xd2+AWJaxu9gxvwXc+D4RVrea pDRITV9yxK8E9PnoM98tMclSFVxRqkA= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of "SRS0=QCtu=UY=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=QCtu=UY=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738451295; a=rsa-sha256; cv=none; b=FicrNfcs0bi9hb4TivbwtgFGdBnmG0zNrfTMDrhUzcM2dl2FUOvc33zOpGjWfouzbdTy+G DOi1REKaw0hE6mtoGjxYp1SSgLRQJi6zJc46qwYuN977Tqr7rCF7+uRCMtfzXLujfw575N 3INSV3fNKA+nE3dX+VvdR6aiM8vxLe4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CC0045C59D9; Sat, 1 Feb 2025 23:07:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9345C4CED3; Sat, 1 Feb 2025 23:08:09 +0000 (UTC) Date: Sat, 1 Feb 2025 18:08:10 -0500 From: Steven Rostedt To: Mathieu Desnoyers Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Thomas Gleixner , Peter Zijlstra , 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 , 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: <20250201180810.1faf4906@batman.local.home> In-Reply-To: References: <20250131225837.972218232@goodmis.org> <20250131225942.365475324@goodmis.org> X-Mailer: Claws Mail 3.17.8 (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-Rspamd-Queue-Id: E2D78C0007 X-Stat-Signature: hjg44osgcwdssk4o9yiccys93rxppzh8 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738451294-646107 X-HE-Meta: U2FsdGVkX18IWMJhDnsvQ/iS/e+lXJ50DqtEXsSnVmuZ+6H7OPwdwIsXObULUcWXgzKxI6G82ZjL/tXQaUMG2mEE6c2NrQakoYHk8L5U1Lp0HaR0T+7d+OTh5S2ePbX4zDvQ1DCXF2yQP2Qu/fbWTXvEth/iepiWXOKiJ+bV+ndd5WP/5SpJA65MvsSIoZ+1RVTca92yXYGVCeohEVbWqkt/9HeSdq1RC001UAbeaExXgwBHoEdN4dSRt/LoqdGIrFi4rtcpkb2Gw/NiD+HGloyRilay5hYsiTl2FsoL1EdcKgwhtEdUmI6D1fdkwY534VhZxnsput1lcEJBBI8Oxs2zSuBUDOHbjzmxhYMs3z7x5MN2nIN5mHPMG0f+5Zs4euqnCOmyKuWKcGFbsxkVPlYRiIp0vZw9VJVUhGDUnn+tnDgBA1MJ6B7q6/zV6GF6Erui3KwwARnOFF13XZGx9Jqi5xe/ihSxGkU1W/DOiD9+AsRXDYX3fkvWQSpEUkCu+sxIlDT9QRmvx5meZAzwcn9ixD6qt+SFqBCl9Ls7/FlHhi1hTssn//5KRBCAbAufi6uWCn0GjSIKmpGpXnoRITLBZJh7+u0zXaqxBq1S40ItQG/7LSwzm6qSirhpmNyiBQl1Y8jLqeRwPxFx6hkq7yoUnW/if4wP2Cqv8YRGekrzB/XuWnKmk76FnRHXKLTBKWQezlxs5odYRaVcOmEKXp9fYILszBkEWXU7D+hLC79aH5Kd6N/GnaeNiGKV6OfzPDFsc0ObGFvuVjRvjBxE3EHtLCB8X+KM0so8CbmVnxbSnp+nW3ZONOgYHrEVrWnczBuHGz3f/nDaKjpV0fwVbhsuXtBlUpk7UaBGlNXrfg0vlpL0menT7yxZmEDs0juCkD8OZXOsaRESdnjtnMahGvxT5oe816W7mjbG5v0o44ruIWZyPlPhoZmXkOssJymkkcMcP/yw+s854YVWnKP PYiLM/2h n35kkFtXa5tV2SNaN6IVzhzc9+fumLOK73UXWocWJMhySmxozlDD/vlESEqkBVlF04jxoj5g05j6wwSpG3kxiZfCt5UH0WFAjBW3RCY8iEi0yneg4bwj0AxQZ+9iHfO2sY5ESUnw6h8QcquAOP+2lDQe7vkOQAt47WEMYSBdTStogUl6+LRUMBIa12cgAb3jvj1+1T6Muw3/IHRhu7/ZXNXi546bD8Glhk6KUV7nSgRNH/AH9eX3o5m7fAvObOf3EGfqUEHogwURbVWVpvRHWspngC055zAAemcL3iR39jPm0Ia+AxptKqEbY/CQngZH+MKfYcil4fL8T/0sjfCxC+lEkOsI404HOa7PadRJ4zOt4AMnqugqVb+4PWtjGOmvP86fX 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 Sat, 1 Feb 2025 15:35:13 +0100 Mathieu Desnoyers wrote: > On 2025-01-31 23:58, Steven Rostedt wrote: > > [...] > > > @@ -148,6 +160,18 @@ struct rseq { > > */ > > __u32 mm_cid; > > > > + /* > > + * The cr_counter is a way for user space to inform the kernel that > > + * it is in a critical section. If bits 1-31 are set, then the > > + * kernel may grant the thread a bit more time (but there is no > > + * guarantee of how much time or if it is granted at all). If the > > + * kernel does grant the thread extra time, it will set bit 0 to > > + * inform user space that it has granted the thread more time and that > > + * user space should call yield() as soon as it leaves its critical > > Does it specifically need to be yield(), or can it be just "entering > the kernel" through any system call or trap ? No it doesn't need to be yield. That just seemed like the obvious system call to use. But any system call would force a schedule. We could just optimize yield() though. > > [...] > > > diff --git a/kernel/rseq.c b/kernel/rseq.c > > index 9de6e35fe679..b792e36a3550 100644 > > --- a/kernel/rseq.c > > +++ b/kernel/rseq.c > > @@ -339,6 +339,36 @@ void __rseq_handle_notify_resume(struct ksignal *ksig, struct pt_regs *regs) > > force_sigsegv(sig); > > } > > > > +bool rseq_delay_resched(void) > > +{ > > + struct task_struct *t = current; > > + u32 flags; > > + > > + if (!t->rseq) > > + return false; > > + > > + /* Make sure the cr_counter exists */ > > + if (current->rseq_len <= offsetof(struct rseq, cr_counter)) > > + return false; > > It would be clearer/more precise with < offsetofend(struct rseq, cr_counter) Ah yeah, thanks! -- Steve