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 1AC36CDB474 for ; Sat, 21 Oct 2023 02:08:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 913CB6B00B8; Fri, 20 Oct 2023 22:08:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C5686B00D5; Fri, 20 Oct 2023 22:08:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73CAF6B00CF; Fri, 20 Oct 2023 22:08:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6154E6B00B8 for ; Fri, 20 Oct 2023 22:08:08 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 321ACC0BA6 for ; Sat, 21 Oct 2023 02:08:08 +0000 (UTC) X-FDA: 81367833456.05.2D17EAC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 54D6D20011 for ; Sat, 21 Oct 2023 02:08:06 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jDkFruvk; spf=pass (imf03.hostedemail.com: domain of "SRS0=3uKn=GD=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=3uKn=GD=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=1697854086; 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=58ihtmZ3yVEPDJYWFggyfxVAmcoYJDmJGropGTJ+Amw=; b=2noFJ1B4jN4sCFf+27HV/nhCjJLiLlDJyHKBw0a/xlm2qnDJqRfotMbeevtJsScM0lHVrb MTfw2agkhdgv9vzxklUzZMOrwdvH+M7DmdcNkuG9do2+fNEeYtXiUx6vK5Clibztxid6VG c2ia4iA4yAOpuN6dFOe7vvBRLk1N4IQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697854086; a=rsa-sha256; cv=none; b=QSkFZxFeeRB7YO2cbvFwZQHM4qWQ7xOiBgAU5OxYDrbdFtT4CRrkp2ZVSVl2DPZYfdqbAS 8Iv5e2+sTOzUBRIGqqvT9j4U47aVoL2J8SooiqsDAyO5YgznfbqOIox6jqyDPkviP4vlJO RAhW9SH3+jSApT6QkSHoZFFpHylsff8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jDkFruvk; spf=pass (imf03.hostedemail.com: domain of "SRS0=3uKn=GD=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=3uKn=GD=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 19287623E2; Sat, 21 Oct 2023 02:08:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57685C433C7; Sat, 21 Oct 2023 02:08:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697854084; bh=FFkjhSKNVgxBaNVTD92muUncILl5qI+VCmPEr544HRc=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=jDkFruvkSA9DNkx41ayqJyrG/JJnFddY5FqdphWlAQz7jxbqQGitFzzBxuwz6e2vO hDR8HaSmVDmmkebxA9QutaTTUbsgZs0a1LUDGBqgMhe/Q3PAdC6QL9HijcFPXo7Bkk yPzczflFFR/ntmRD0db+3xW8Kbo7UGwmi3o+i1mWaiO2ynPzy63phNmt22m1XoW+jE NgEZMrrrMKCGPvFKS7/Bbn7NBGeQttuN9/qjBDZ1HIYNNNxfRSZ2RaN0Pm7HTTiUKV s3nCPOmFIwGLQCwVSeY6CFBizZkSLXJw/WpVETx5dRCYilWzjeIJfJj7/TcHs8Qjdv Yg88DH2xKJ1nA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id DBA12CE0D14; Fri, 20 Oct 2023 19:08:03 -0700 (PDT) Date: Fri, 20 Oct 2023 19:08:03 -0700 From: "Paul E. McKenney" To: Ankur Arora Cc: Thomas Gleixner , Linus Torvalds , Peter Zijlstra , 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, rostedt@goodmis.org, 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: Reply-To: paulmck@kernel.org References: <87ttrngmq0.ffs@tglx> <87jzshhexi.ffs@tglx> <87pm1c3wbn.ffs@tglx> <61bb51f7-99ed-45bf-8c3e-f1d65137c894@paulmck-laptop> <8734y74g34.ffs@tglx> <4c7d06b9-8f5b-43ff-a2d6-86f54116da52@paulmck-laptop> <878r7wlx7d.fsf@oracle.com> <87r0loiy3y.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r0loiy3y.fsf@oracle.com> X-Rspamd-Queue-Id: 54D6D20011 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: b3jrxrinpf6ojrdmu5j4s5if8w5zhsuq X-HE-Tag: 1697854086-136175 X-HE-Meta: U2FsdGVkX1/VkFZV/osazwZQieaz05G+GOHRQDPu6VevaGbTjaki/7IOouwz7O2W7Pu3+45oCVsYjdrUJ6w5F3wp4Mfa+A+3YihSptlzicNJ/K4TTgV5/QufizIPUzeGuJVsYtp0NwcwAKhaRbMQjuV0QyQ+Ac7GGRZr5pN0aU9ImZ5Sg7AiBA4k6vCzc8YLjv3QJ/2B4/Ff2ILZRBdeqTLC1msjxb5HvSHVeNlhPP5PbD9BopdbVd0BTUhl37nuNLFo2yDXIGrISI6DBKujVmK1Zvi65U7EZnS9khm8DJK4sH0O7Tuv0HfYF0C+5tyUc3IAMuYENFHbfXX1B2qX+w36bt+RtUtI5WLKZZxKWeZ2YWQNaiCXPnZeT8UE+LUn7K2MfXdp1/74TkvGm0L5zrK4PzNAAbtQpr33dvxw7iSTvC87Ouhj/fHRrfjAxGQLK5JQJDDLZS7UczGOBsfZulKCRefK3kr1Jhi6B62v4c802T3fSAc22UFcJTjRByvVgEO4Ztys/+wOqAxYn0xYuKvh0OlHNWC8gZKGi/yN5knzMW2Z+z5VfIvV9TXD5ZxHR5IYwlKU102zevQTCKoY4Jo9ACUxjhXG1W20MPiparRS7rrFnYWEHOH98QWkSZYFTS9hbjVwegATS8Q/SZw5Nxp8+vtEdYHWYtofQl8+nYlTj+J4aw6Fc3sQROriN22Jfg+e8NSGUK27f4WegWVYYiAgU3DBaRL5yYHH7oHSfahszpn6JhTWYfgPVVuggUHWmPDv3it0ujq5G/QN8Z+KDxoU9sdbrEnZCmb8WZXJ7d9TnNxVpVqEksUJJr2NdrGFyR5aGHDgLn2+b/mUDokj5nZPs+8dliFfVpcOjnIe35rR80QaDJlcLmBbbdQtZ4eTUTROYp/A8HNPOSmQiYH1Tc39O32l9Bs+KLWvoeGgNNwINVpiE4ldt02qezeQVUU4Gb898di7DoWtpgZqsrv PMzAnPLq 3scdgmQEtJvqTbX6VSiQH+5i4Yq4crT9+kT2dmvKRp+W7YmegYoXqwIBVTv//qqjH6MnNzIlmGascOij3F3ZXOtsrH/iG3KGYV7atMxyDYzeRy+v1dvtr/GKQVlv5a38SpEvL8v3B2wkuhF9DVwxlawsciuiSEIup9rsceYBn/FJCd1FH7cGR2GRf7mG5Nj2bRIxSV/HFrPlWAPcWfReLmswuQY/gI/48+L3f6/IjcNtBr0ZxPG6/lBYUSGqRHDJXItkbB8Nwl6ygsDd3XLjSZx2ZHlYc9PxgrNRfaHBlSuVpFOXFOPW5FJ8/9UMhTP2iAay9gVvwMV5KEA1GhjBG1wGEYPUmihuBmRY9Jetq3S3gIA+8b0R7Itf7/9hAYx0Nd1bmJ8PmQyzyj9JV3TOIgis+K4EEgLbJLblkFO5nHN1yULlbsR4tuALWuBbVKyPa3bjNeZQQB5IJI4Dz2YaS0QCUA2QO+eIDZ4rfnK0wVzeDr13Qp7FQIpO2cTqF8vOS4AOMXFxPPajUfx/cnw1mrJZMvgw3O2r4oNSgvJbCHklRXSxjL29alVnUck9trRrkIpP7VrSJK9Csx1cGrk71tQRxw8O8H0NakAM4GBIPA0m5zNWCDU1nGNivBfXG8ldHtEjEMgctEfTQ2Pk= 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 Fri, Oct 20, 2023 at 06:05:21PM -0700, Ankur Arora wrote: > > Paul E. McKenney writes: > > > On Fri, Oct 20, 2023 at 03:56:38PM -0700, Ankur Arora wrote: > >> > >> Paul E. McKenney writes: > >> > >> > Thomas! > >> > > >> > On Thu, Oct 19, 2023 at 02:21:35AM +0200, Thomas Gleixner wrote: > >> >> Paul! > >> >> > >> >> On Wed, Oct 18 2023 at 10:19, Paul E. McKenney wrote: > >> >> > On Wed, Oct 18, 2023 at 03:16:12PM +0200, Thomas Gleixner wrote: > >> >> >> On Tue, Oct 17 2023 at 18:03, Paul E. McKenney wrote: > >> >> >> In the end there is no CONFIG_PREEMPT_XXX anymore. The only knob > >> >> >> remaining would be CONFIG_PREEMPT_RT, which should be renamed to > >> >> >> CONFIG_RT or such as it does not really change the preemption > >> >> >> model itself. RT just reduces the preemption disabled sections with the > >> >> >> lock conversions, forced interrupt threading and some more. > >> >> > > >> >> > Again, please, no. > >> >> > > >> >> > There are situations where we still need rcu_read_lock() and > >> >> > rcu_read_unlock() to be preempt_disable() and preempt_enable(), > >> >> > repectively. Those can be cases selected only by Kconfig option, not > >> >> > available in kernels compiled with CONFIG_PREEMPT_DYNAMIC=y. > >> >> > >> >> Why are you so fixated on making everything hardcoded instead of making > >> >> it a proper policy decision problem. See above. > >> > > >> > Because I am one of the people who will bear the consequences. > >> > > >> > In that same vein, why are you so opposed to continuing to provide > >> > the ability to build a kernel with CONFIG_PREEMPT_RCU=n? This code > >> > is already in place, is extremely well tested, and you need to handle > >> > preempt_disable()/preeempt_enable() regions of code in any case. What is > >> > the real problem here? > >> > > [ snip ] > > >> As far as I can tell (which isn't all that far), TREE_RCU=y makes strictly > >> stronger forward progress guarantees with respect to rcu readers (in > >> that they can't be preempted.) > > > > TREE_RCU=y is absolutely required if you want a kernel to run on a system > > with more than one CPU, and for that matter, if you want preemptible RCU, > > even on a single-CPU system. > > > >> So, can PREEMPTION=y run with, say TREE_RCU=y? Or maybe I'm missing something > >> obvious there. > > > > If you meant to ask about PREEMPTION and PREEMPT_RCU, in theory, you > > can run any combination: > > Sorry, yes I did. Should have said "can PREEMPTION=y run with, (TREE_RCU=y, > PREEMPT_RCU=n). > > > PREEMPTION && PREEMPT_RCU: This is what we use today for preemptible > > kernels, so this works just fine (famous last words). > > > > PREEMPTION && !PREEMPT_RCU: A preemptible kernel with non-preemptible > > RCU, so that rcu_read_lock() is preempt_disable() and > > rcu_read_unlock() is preempt_enable(). This should just work, > > except for the fact that cond_resched() disappears, which > > stymies some of RCU's forward-progress mechanisms. And this > > was the topic of our earlier discussion on this thread. The > > fixes should not be too hard. > > > > Of course, this has not been either tested or used for at least > > eight years, so there might be some bitrot. If so, I will of > > course be happy to help fix it. > > > > > > !PREEMPTION && PREEMPT_RCU: A non-preemptible kernel with preemptible > > RCU. Although this particular combination of Kconfig > > options has not been tested for at least eight years, giving > > a kernel built with CONFIG_PREEMPT_DYNAMIC=y the preempt=none > > kernel boot parameter gets you pretty close. Again, there is > > likely to be some bitrot somewhere, but way fewer bits to rot > > than for PREEMPTION && !PREEMPT_RCU. Outside of the current > > CONFIG_PREEMPT_DYNAMIC=y case, I don't see the need for this > > combination, but if there is a need and if it is broken, I will > > be happy to help fix it. > > > > !PREEMPTION && !PREEMPT_RCU: A non-preemptible kernel with non-preemptible > > RCU, which is what we use today for non-preemptible kernels built > > with CONFIG_PREEMPT_DYNAMIC=n. So to repeat those famous last > > works, this works just fine. > > > > Does that help, or am I missing the point of your question? > > It does indeed. What I was going for, is that this series (or, at > least my adaptation of TGLX's PoC) wants to keep CONFIG_PREEMPTION > in spirit, while doing away with it as a compile-time config option. > > That it does, as TGLX mentioned upthread, by moving all of the policy > to the scheduler, which can be tuned by user-space (via sched-features.) > > So, my question was in response to this: > > >> > In that same vein, why are you so opposed to continuing to provide > >> > the ability to build a kernel with CONFIG_PREEMPT_RCU=n? This code > >> > is already in place, is extremely well tested, and you need to handle > >> > preempt_disable()/preeempt_enable() regions of code in any case. What is > >> > the real problem here? > > Based on your response the (PREEMPT_RCU=n, TREE_RCU=y) configuration > seems to be eminently usable with this configuration. > > (Or maybe I'm missed the point of that discussion.) > > On a related note, I had started rcutorture on a (PREEMPTION=y, PREEMPT_RCU=n, > TREE_RCU=y) kernel some hours ago. Nothing broken (yet!). Thank you, and here is hoping! ;-) Thanx, Paul