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 AD0F1CDB484 for ; Wed, 18 Oct 2023 17:59:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 377228D0181; Wed, 18 Oct 2023 13:59:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 326FC8D0016; Wed, 18 Oct 2023 13:59:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2160D8D0181; Wed, 18 Oct 2023 13:59:46 -0400 (EDT) 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 10E578D0016 for ; Wed, 18 Oct 2023 13:59:46 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DB776A0D73 for ; Wed, 18 Oct 2023 17:59:45 +0000 (UTC) X-FDA: 81359345130.14.CDC6078 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 1B9208000B for ; Wed, 18 Oct 2023 17:59:43 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mESBSMwr; spf=pass (imf02.hostedemail.com: domain of "SRS0=oRJs=GA=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=oRJs=GA=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697651984; h=from:from:sender:reply-to: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=n1OX2zwxmO5fYpo1iocxKsgL6jXooGmH6VXWXR0B/C0=; b=Aw78n2bU2un9KVcxqPD+lOMhkGhMMbpBSRpisHf9Af8X7uygXZ4Z82Qp589ALhPuTR3c1U uFwThPF3yyur5eo6VS4hQYYhFWmKeZAOTegxZ2GW1BwDfA0cAcUe2jlqmdJ9gKHSEq/cld /rWWudPja9JoldtD3kicHyIZjeGr1VY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697651984; a=rsa-sha256; cv=none; b=sGgKYYlgJV30FDDlEk64BVRXBGzHaO5nLB3h6uR1vGUjst78sB4GBSLOWWtj0lKN4KI9Ji dLI+pyNpJmMjXG3NAVm/USUIZOCDsIhZdPwogou41I8M4KZnwlYm0FuqhB+j5gW+aNRJMZ hDSsI8WmZR9DlW5Va1UEPCqE5X+ujTM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mESBSMwr; spf=pass (imf02.hostedemail.com: domain of "SRS0=oRJs=GA=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=oRJs=GA=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 18A7661888; Wed, 18 Oct 2023 17:59:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD54AC433C9; Wed, 18 Oct 2023 17:59:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697651982; bh=8G1OxKOfk68WbZVYUB5YAFZhu1uCaWJkAzB6k9kgYD0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=mESBSMwrU+w/PCBKSQQy2t2YDkDC5tiSnWJBi5cnZDPJwJMtMIYhKTCjqK13A0EJW BWFOfktXcQ+2JKRzkwQMv9WlTFOjES7/y0EBtwihBD4a/4BduExFkCviIHuafe2ERK sBdk1R4sPnhHLahLFtrbTKQ4HY69/PE+ZBRNC8p7BlNrPxbN41lj44wANSDXTgp5nK BRLtckwBOrJA22ePQoN5ifLFcTQgcwZBd4QONjGtZxxKKa0c3d8lFwtEJRhpGIVxpq 9bpkDs3Ul+2pHPkcw3wwtBt8wnxiRLgf6SKnJgpul1SKI/OTMmdXI+minYamUP3PF6 S8wSkE9yuBt0w== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 4CB07CE0DE3; Wed, 18 Oct 2023 10:59:42 -0700 (PDT) Date: Wed, 18 Oct 2023 10:59:42 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: Thomas Gleixner , Linus Torvalds , Peter Zijlstra , Ankur Arora , linux-kernel@vger.kernel.org, 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, mingo@redhat.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, Frederic Weisbecker Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Message-ID: <8ab0ae35-9ad3-40cb-8ee8-3801bec0213e@paulmck-laptop> Reply-To: paulmck@kernel.org References: <87ttrngmq0.ffs@tglx> <87jzshhexi.ffs@tglx> <87pm1c3wbn.ffs@tglx> <61bb51f7-99ed-45bf-8c3e-f1d65137c894@paulmck-laptop> <20231018134107.1941dcf5@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231018134107.1941dcf5@gandalf.local.home> X-Stat-Signature: ity5knu5ct38hpjzag3nzs3xii8jh6ib X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1B9208000B X-Rspam-User: X-HE-Tag: 1697651983-51771 X-HE-Meta: U2FsdGVkX1/hPrUf5f3wyw4HM/drvnH9sStAn61/fnZ6bliPf7ZedIt5xpPTXE2Ccij2g8HEC3wzEr+DLpSzT5Dsa2tU4ah1emiy7gO1jCntpT6a+6RbOjIRkzUSA4gbtyAv1ORO7lBrVOxnJIOeE/Ls0YMlYqeptydX6m/A/FkNXU/jqmv8MkErgg2xOk0WSHsV8AuecBKMVVXmqFNJ9Tx3XQ5Mx5N2hBRidZm8BYsVMcBwFp+cyGtQnt/IKoSzsGMsiI2z3Y67mhZHosWoXkzMWcqQIlQjqAQjhcV9mV+UVymrMCgpnKoGRnbH62eCVaQsBMqWMc5u9TnvyecvNzZU8pRbVZEcmf8WkCwaXVcIf/hUynzwrkO9/6/G/XOEDHaDDCeN8OdjR4V2Q9Xi0YsZOFbweUob7slDF/YAxvEWCTAfbLgBowv9Dp06FGZHKolh/aTJ9jl+Uukdou7lahcMO+e7gDUmgLwdccHstrwlwPkImqF7JLgNutozxapByrabRH5Wt+We8xVr5gy3KtflbOgwkmU38AbvbmacoCR3CxHNdKNf4lyBg7sb332FWFWeu+0ecxXFIskRNL6uC7NvJdVZ+TgZ3QzwBpx46bmYbRgGvKQoWlk8DRhXOGlCiThTmgGCTdstjHussxZSN7J6dJhO4cTdWzOAhI3k20ZVQxainz13qh4kph80uqaU4E+Yspt+wTYM4KFNFV9gh1C1AqY7oAU0+Eyq8Fo/ptXRZhkhMWHDlfGry7wv+kvieK97+yEQzIcurdQuR+wYIKKdRS8eEoc+0vndp9y0EckLDKbZHwOl+EXwxgWf99lFWX4UVqcBe5Z8CdxVcrMA4Auugyt3JJyjYETx9VaS03cOu/aOFFJkHB9vKAEjNU2qMKUmgses7seOHIxkn3HOLSVdPBXxvSpHfsCIO13Nm4HJeDbd6pea3019l6mXKqNoj7cVvOLLbd4YNL3Hhxb LttbwCgv hWMojdaM6+6Y2pgN23rphltrtyZLWYefnxmdUrE//9lAYQCSYm019VMXT9HFVU7cC2Z6Y71zKccxHjaJEMGZ+Lpj0HVeNoqY5jgDY4t5iO98JdppqQ3NFIzR/wn8r34h9/JR8FnuIUv86Mi75iXY1sjdhrcvJGVYhnTrto4YYb3KwtuZaWe4q85YEs4bDgwDS2ubbz8kC3TXjlbtGkiLKTpJs1Gsr/zTgG3BZFR32tedTPAqiBX5cNjogPxUYg6XmAgS6DC3OKJWIOucLN/ZjdgfoT6oUi0j1UDztYmTYiPb/CFg9LjbHGkaoeAV/DNgc6UsYhWirh4eC6EAjAbUl2wKY3Qa+NOiUYQNzEYDyCJhbXc4rfgvIFxgJRbNrjNui42yCg4A1rGIIsVOwMbdYKjvWWVR7XcGo35TRjuyncf7d0IkreaY1B+TzMDV7WQG/ibPRPpMxCVwIwQ+RqpWi0gE+UREyy5RXpzCX6kFXEK4/gH2vlfMXEAc2IsgDNYmT+0tbgzU3SflptfvSXkpcS3lSXjwm/TguVoS3MAFI9IboSiwxcAm4LDnAwCoj4w8HFSrkWiqrMYKXCMuNLXFRUTXINOYmKt4Q4G17yfJ+GX9BXWqnWJJSRbjQuYH5yD/QjY3dE/f5cyBmGRM= 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: On Wed, Oct 18, 2023 at 01:41:07PM -0400, Steven Rostedt wrote: > On Wed, 18 Oct 2023 10:19:53 -0700 > "Paul E. McKenney" wrote: > > > > Isn't rcu_read_lock() defined as preempt_disable() and rcu_read_unlock() > > as preempt_enable() in this approach? I certainly hope so, as RCU > > priority boosting would be a most unwelcome addition to many datacenter > > workloads. > > > > > With this approach the kernel is by definition fully preemptible, which > > > means means rcu_read_lock() is preemptible too. That's pretty much the > > > same situation as with PREEMPT_DYNAMIC. > > > > Please, just no!!! > > Note, when I first read Thomas's proposal, I figured that Paul would no > longer get to brag that: > > "In CONFIG_PREEMPT_NONE, rcu_read_lock() and rcu_read_unlock() are simply > nops!" I will still be able to brag that in a fully non-preemptible environment, rcu_read_lock() and rcu_read_unlock() are simply no-ops. It will just be that the Linux kernel will no longer be such an environment. For the moment, anyway, there is still userspace RCU along with a few other instances of zero-cost RCU readers. ;-) > But instead, they would be: > > static void rcu_read_lock(void) > { > preempt_disable(); > } > > static void rcu_read_unlock(void) > { > preempt_enable(); > } > > as it was mentioned that today's preempt_disable() is fast and not an issue > like it was in older kernels. And they are already defined as you show above in rcupdate.h, albeit with leading underscores on the function names. > That would mean that there will still be a "non preempt" version of RCU. That would be very good! > As the preempt version of RCU adds a lot more logic when scheduling out in > an RCU critical section, that I can envision not all workloads would want > around. Adding "preempt_disable()" is now low overhead, but adding the RCU > logic to handle preemption isn't as lightweight as that. > > Not to mention the logic to boost those threads that were preempted and > being starved for some time. Exactly, thank you! > > > > 6. You might think that RCU Tasks (as opposed to RCU Tasks Trace > > > > or RCU Tasks Rude) would need those pesky cond_resched() calls > > > > to stick around. The reason is that RCU Tasks readers are ended > > > > only by voluntary context switches. This means that although a > > > > preemptible infinite loop in the kernel won't inconvenience a > > > > real-time task (nor an non-real-time task for all that long), > > > > and won't delay grace periods for the other flavors of RCU, > > > > it would indefinitely delay an RCU Tasks grace period. > > > > > > > > However, RCU Tasks grace periods seem to be finite in preemptible > > > > kernels today, so they should remain finite in limited-preemptible > > > > kernels tomorrow. Famous last words... > > > > > > That's an issue which you have today with preempt FULL, right? So if it > > > turns out to be a problem then it's not a problem of the new model. > > > > Agreed, and hence my last three lines of text above. Plus the guy who > > requested RCU Tasks said that it was OK for its grace periods to take > > a long time, and I am holding Steven Rostedt to that. ;-) > > Matters what your definition of "long time" is ;-) If RCU Tasks grace-period latency has been acceptable in preemptible kernels (including all CONFIG_PREEMPT_DYNAMIC=y kernels), your definition of "long" is sufficiently short. ;-) Thanx, Paul