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 A8DF3C021A0 for ; Wed, 12 Feb 2025 15:19:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FEBE6B0085; Wed, 12 Feb 2025 10:19:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AE7B6B0088; Wed, 12 Feb 2025 10:19:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12A9A6B008C; Wed, 12 Feb 2025 10:19:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E57876B0085 for ; Wed, 12 Feb 2025 10:19:05 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AA055B33F0 for ; Wed, 12 Feb 2025 15:19:05 +0000 (UTC) X-FDA: 83111650650.13.B206C0A Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf13.hostedemail.com (Postfix) with ESMTP id D494D20004 for ; Wed, 12 Feb 2025 15:19:03 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="mLs/pvF0"; dkim=pass header.d=linutronix.de header.s=2020e header.b=Iy2yhe6t; spf=pass (imf13.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=1739373544; 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=MyC8nPx9XyKsxgGOclxuEanrBYS66ka1otwb7a83Bn8=; b=nDtgH1nposBABq8dm7WTV6s28iMP2QbmjDeCocGxBCGT5Wqs1FnX1suVLqIIGu8YDsjMwu z3xyQ+rDXnrqihmsuoIw65uIvSkSpzxyk1H4JrU4LCqg3kUw4tOC5tTo3PoU1UbQ3d1cEc GEnxHUqVnOX4CxqSHj1/XIAvjul4JwE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739373544; a=rsa-sha256; cv=none; b=dErFaGybh3RmkN8z+7/3ht5OSeeu43UUOSbOOhM6mdnFMX95tG32onkr+3LC9Ap65s+Znk 4SswNkO1rsvp5z3w5fkLkDGZL5hVgYdKx8OnnBqtsH7N2typivNp5iswT+vHhe7so8kQda jyx/k8O3ZG0Zx4jH/PT8tEFs38Misy0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="mLs/pvF0"; dkim=pass header.d=linutronix.de header.s=2020e header.b=Iy2yhe6t; spf=pass (imf13.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 Date: Wed, 12 Feb 2025 16:18:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1739373541; 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=MyC8nPx9XyKsxgGOclxuEanrBYS66ka1otwb7a83Bn8=; b=mLs/pvF0wNkcQ6mi8W2U0gSCYzyBuhNTofSL6cX7+ABTzDIzYitGXy9Rh0XAWVe4Qq6UbS GI9hs0wB2s/yVqADWEhIZGZSALez4w/3EEkFglzecIGaTWL9hjAmdNq4jhz5gfqect8IDo NSsedK1jWvsefTMx/jKkbpRUK1hqz/asg6yF+Yh68Zud9O6+0CJztw0xzBmsoRXtIy2GsF R8arANlH1NWCswyNOcwTjk8aGU9iGdE81Fea8l+8lfucvwzGLdRxJKbfJcGVOSRrre5Kgg WNAZyitl568HhKIAbT8BPENSKjsfMgj+utrm1rGfGWAPKC0pTDNZLbZerLxUtg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1739373541; 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=MyC8nPx9XyKsxgGOclxuEanrBYS66ka1otwb7a83Bn8=; b=Iy2yhe6toMtrWIbp8JHYMexS9Nz6+POwywhYXhaDhFrQOQkaKTigj51UDF5FQnxNjSbPfk WQY/dLcjl9Ep2+Aw== From: Sebastian Andrzej Siewior To: Steven Rostedt Cc: Joel Fernandes , 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 , daniel.wagner@suse.com, Joseph Salisbury , broonie@gmail.com Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250212151859.pHAFF1Xj@linutronix.de> References: <20250205081635.397eacb0@gandalf.local.home> <20250206083039.0916ad24@gandalf.local.home> <20250206134408.lD_POjuG@linutronix.de> <20250210144321.1f5974a6@gandalf.local.home> <20250211082138.iqvedSfG@linutronix.de> <20250211102801.5b32d610@gandalf.local.home> <20250212121113.3nJ-kf-6@linutronix.de> <20250212100001.2e129b62@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250212100001.2e129b62@gandalf.local.home> X-Rspam-User: X-Rspamd-Queue-Id: D494D20004 X-Rspamd-Server: rspam07 X-Stat-Signature: cc9amsgs9o4zedof1b34ma4dby38u3rf X-HE-Tag: 1739373543-113174 X-HE-Meta: U2FsdGVkX18E85q/7M7gdgGs1YSbm8Ofjc7JMt2lhtf2Duny8P/O8FFBHeDe8MdVsFhjQ6F3Nvz/D9a2Gl+Zsnk91KMilblXKvfKDVmcX8FdVQriB9hDd1EwZIacx5lifFAtXlqUS5Ssno9P4Pm8XSOqmNmsU+B3Zt6B4GOD3SV6nuCeFbKG4algvBAt7zNxKxTlqYW8SP99x/FExfiHIowkuM0pvpaWB9CRT0MOB6ktUQ8yDyqzYZNVnqTuYF5OnFRd6keI+icQ/wAoFi059BgW9s1++wUQpPzZInqdUirzrIwbgUVAgnDI05m2ZHB7Eg6VM4X4aIwVHu9TNUTTFHhy2biqjdnPBg/1U7/SO8VcM1MrFrJyEBbtszNDMPQP8gmE9b/X15HYpp3BqfCemh4Bx1C0D0cL6W6tKBWLz08zMNPXsjJ0FHEbYu6cPpiVqvbkUKriLKNNWWjx3QbZolEWhqx6Np/cIcY3ja3xzkCvM+ZDy5jUQ2pKiGrUyjdqctWghpj0NQqqxT+Np0oGgRxbmnRqGSKN+/ATnf3J6sOWAisCOeBk95PE2mvZ648lcV7NEYrdo1baTqZN9DW67HwsLUPYNGAD7aP9NSFnRn1uh+AEs5u2Gtug+k5KUhB1Ls7Hm21A28KKBOK7sTwLF7WZmzRtsHIGvwXAZ2Bh/1Ahq7PXShQ+6Mkoy6rw1vI0v3lyyVMfdeJ0WCGmt7/2QrVEML1RHycKzlF/HLDiA2iZF0gHrJvOA2JKl6YQZCs0eA1wvCoJNyh9dBvPAk7tJB/5eXGpumu9r89iEQ9xr81BMJ941n8h9UXNlUMhojqQb3ktIydVrh/+4Rr+R+oC9EABWoBrsVSCWypCxMc+Dc9qyX/nmqIB9GfdMSY2QlJXouoc2gQOYye51nmclic9ECo4wjsU+xB1ZCsDhUphSl1YxvvI30xBTKvbPUd7A6yWJZm4uSpI/4vTpPnEokP O4g3KoyJ QNfQ+Q+dxya84bIb/XZCmEYG8oeetd24aAp9RIQhg/bHfufcy6cwqxevhWncE5qj0actxzH4dPaQk6CnDhvE1o3xXKQ0ELfPaU7Nwzj6vW35FoLc7jlzskgjy4FjqnJvNphA2LBSs861jNzyyyETIU/Z8JU0FJ/hBY2cDs9hg1yl1m+bN3c/VxyiU81aAgZBz0zdoV60h6AFUsq81HH6gnHxW8RXIt9ZEgI9aKnZ/jdw6UgmFHgdfkGs4BGWChv0QJmPvnDsKImgkdGo= 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-12 10:00:01 [-0500], Steven Rostedt wrote: > On Wed, 12 Feb 2025 13:11:13 +0100 > Sebastian Andrzej Siewior wrote: > > > IIUC, today, LAZY causes all SCHED_OTHER tasks to act more like > > > PREEMPT_NONE. Is that correct? > > > > Well. First sched-tick will set the LAZY bit, the second sched-tick > > forces a resched. > > On PREEMPT_NONE the sched-tick would be set NEED_RESCHED while nothing > > will force a resched until the task decides to do schedule() on its own. > > So it is slightly different for kernel threads. > > Except that it should schedule on a cond_resched() and the point of adding > LAZY was to get rid of all the cond_resched() which in turn gets rid of the > need for PREEMPT_NONE. Which was what I was getting at. That PREEMPT_LAZY > is really just NONE without the need to sprinkle cond_resched() all over > the kernel. Instead of having cond_resched(), we just wait for the next > tick. I would argue that we want to get out of the kernel asap and not schedule() if we stumble upon cond_resched(). > > Unless we talk about userland, here we would have a resched on the > > return to userland after the sched-tick LAZY or NONE does not matter. > > > > > Now that the PREEMPT_RT is not one of the preemption selections, when you > > > select PREEMPT_RT, you can pick between CONFIG_PREEMPT and > > > CONFIG_PREEMPT_LAZY. Where CONFIG_PREEMPT will preempt the kernel at the > > > scheduler tick if preemption is enabled and CONFIG_PREEMPT_LAZY will > > > not preempt the kernel on a scheduler tick and wait for exit to user space. > > > > This is not specific to RT but FULL vs LAZY. But yes. However the second > > Not true. PREEMPT_RT use to enable PREEMPT_FULL as well (it would preempt > everywhere). The issue we found was that spin_locks which would not have > been preempted by just FULL alone were being preempted when RT was enabled. > That caused a lot more contention with spin locks in the kernel. > > That is PREEMPT_RT with PREEMPT_FULL will have a noticeable performance > degradation compared to just PREEMPT_FULL alone. okay. > > sched-tick will force preemption point even without the > > exit-to-userland. > > > > My question still stands. Have you compared PREEMPT_FULL with and without > PREEMPT_RT? No I have not. > -- Steve Sebastian