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 A88AEC001DF for ; Fri, 20 Oct 2023 21:59:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B75A8D01D7; Fri, 20 Oct 2023 17:59:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 267F38D0008; Fri, 20 Oct 2023 17:59:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12EDC8D01D7; Fri, 20 Oct 2023 17:59:49 -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 02D3F8D0008 for ; Fri, 20 Oct 2023 17:59:49 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C842612098E for ; Fri, 20 Oct 2023 21:59:48 +0000 (UTC) X-FDA: 81367207656.01.F17C076 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf15.hostedemail.com (Postfix) with ESMTP id DA2CCA0016 for ; Fri, 20 Oct 2023 21:59:46 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r7bFA6U9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of "SRS0=J0PA=GC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=J0PA=GC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697839187; 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=F9H2YUf2KA5Y3fflJidU6uECUwFhtmgdChR2fPgwcmI=; b=G4wEiWUL/7N/p4/k6SPGNHu81w6/AE1JwQut+kQNVHoZrU62msjoEBoxZMtFa4sv/YPJig 7jIjwwHLsBxv6pKYbdWl8Ib2ePriYKl9r6Rf6/zCC1rpTG9GYdVEQJwK0HATPBUvosZi+l 28MZSZfJmrwcrkU1uJUbzvmOeFaM91g= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r7bFA6U9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of "SRS0=J0PA=GC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=J0PA=GC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697839187; a=rsa-sha256; cv=none; b=UBEYPILOWPeCiAe/M0s1wZ4vkWabO9kOEYofiRzgrlg2ib5UWL4eK0SKTgwbNUu8rP1wNN C08ahyg4/Y2TsXD8Kq8QylyUxbGjxrccUVKIFd76d/jMTH2L1HvcCuxIBsvocDUQlndw3z Tw0OeT0hGd6xWF+RlWonm7+1jkPuDSU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id CB050B832B4; Fri, 20 Oct 2023 21:59:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 201EEC433C8; Fri, 20 Oct 2023 21:59:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697839184; bh=LJ9TGwTP0Yf1kpT07kYu5R4YBY2Xfhzc1X/zqzKAkZA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=r7bFA6U9EURnDdC2UmMIP54MzcJo73i0b5f+xB0iUgRcDANtnfYsFcOol3WG8GCSg PTDBobB62rzUouX6Ts31fQz3YmtXXSZpT99f4+FEWdHp5VvAOgWlMZ6aORn4JgpOr6 q+oAcc57o3ZGUvONBxXE4d7sxnjKh88dXTFoFpU+cOUp+1uw/m0NSvoZbDSOEnXEL+ pJsDf70xYoulinLCsM/hkPPYN9KMo2xWFfyZyhGzsLxMEyPleCozx5/ONBffv6i5TN dh1hsW899jHFeymYUbM1lNGK4TvBYDTyY37nIW/1sLdsxHENRYwmdoFvZYbMgN2vxu 3JzKmd1oC/aZA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id A79A1CE0D14; Fri, 20 Oct 2023 14:59:43 -0700 (PDT) Date: Fri, 20 Oct 2023 14:59:43 -0700 From: "Paul E. McKenney" To: Thomas Gleixner Cc: 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, 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c7d06b9-8f5b-43ff-a2d6-86f54116da52@paulmck-laptop> X-Rspamd-Queue-Id: DA2CCA0016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: eb5qcz8cgifz69n4a93erbwtphomh15x X-HE-Tag: 1697839186-638591 X-HE-Meta: U2FsdGVkX19rCgWrZ5yMv+tQ3k/tFXUgtY14QgnPz7m4t4n+BYvgFL3Lmqm7EJ2hYJ1Y8T2whuGLks+0qXPa9Uxgwrzu8qW//T33eU28CsDhrdlbywGOP3ChISSc7p58Wb2Dyyw/IYFzkOtMpsnTXyaqVol8KxJl+TsQpJp3wmdbk/9jvyha/nEDuu5USIHA+MsoPsu/YwNyVQfZE4EpwbNC5g8bLoWazcC/SCf1gsaSSeK0yjB66prgM+C2erJcItO+wyNsVmo13jMDIID+mag0oPiolsBzOQ75MHpwJpPSebhXFQu6RuD0PuZWKoEJzUKSn6BOb5qr3RyI9TsvydU0mfkySC7FACT6JMett9GTvtW/odlSJOmii2j+B/12HtBBCX+Rgr/caAymyluLePvEGbsA/6DZpVNmNCYlnUZEpCtOd/93KaeeItjFsyVjjQ2G6Hyzo0BHNLwU8wOmTP7mJL6zdQ8No1K7gmC4I/CXbGKINpEwvwJ1XBLZqMybZriWeXa853e0Tjd/DqPui3Zy6z8DaYpqrxw+kU4AIl6PG2aCsGwMcq/TojxWVD3iaLIZxuuftHQtsmrX6Z2AQ5hvuJsIDUlrXp74FxFPDYuIdIFdrgQir53T/Kk8EwFAlFVyTJtJbhEmkSYnxJAvLfYD/kcwjhQI0UaFuJ/GideqO0WRSvEirZ5AUzMNidRkOPmY9IkB0F61/C6InRnZ1I9ShxgfSipRvAzrDnquyHKS0Q7OBVa9M4xzskvtU9v9FmUg1qNLVzB8GmTXDoUoAoXOJCg39rQulftJckzBoP0MKbj47TkR8kAV4Y/Hg2mxIVtUNQVjj8GauL6gxA1Yd2Cju/hlRaywHzUeFxFDWHMcUeV46xS3Eig9Ojz7UtGoGCbqWeOuKiNOpC8gP7jbQ+Bmr7UDbVPDynCbYd/yAI5PhZzYffKTFEvMEozrNzngm/kG4jFL9xvbT2OxdWD eX8npukv k3Nm6Li6o6aNsjdLuYJGjr3w6bOmx3frl0KdPrHW/mfNPzypwz4QegzgJE7hYBSDC8k03R+9TAaUePRHu3rQCJRDFPP+2a+bDspObxAj35qS63mr9s/1mz6N78udIsWJRxi4hphIdh2VYYj/wm0XxfiVVKb788+L1Xs6HDAiy6kTpFVzShFlcYiF/jptr4s+0nHXgr3gEZZ30qbiVZDBeUA0/9G72pW7P7Qupc4KB3bqASlglbdp4j1/oWHJPgGPRMRfIQO/DkXb+imfvfBBCPjTwo1uzZi5KZa9WofSSTZbzl4xYPuz6VZWualwCAmTi2Et631C1bT5cfUOX7Yuf+AB3b5/N16+f3RhViCKcy0HlhB8bXWvhasduau0hxO+wHeBw9UMG5PibTLTWCyGqQlpLIsAUnyJDmyooy5enQ1uxxtHMhwYY6fL/WmylUvauMGnW8JBobFYDHY8o6Bq1MJWmkiUamexvhdUffSPINEfPrpWqpnhji584mvC02hsz/JGHQPOXO0jb8o5e/9hl3h72jwpjLZwitEup0Lxa24R7NsWN9GgVrrgyUMXBMRbIx/R0QidgLoh9+6g= 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 Thu, Oct 19, 2023 at 12:13:31PM -0700, Paul E. McKenney wrote: > On Thu, Oct 19, 2023 at 02:21:35AM +0200, Thomas Gleixner wrote: > > 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? I should hasten to add that from a conceptual viewpoint, I do support the eventual elimination of CONFIG_PREEMPT_RCU=n code, but with emphasis on the word "eventual". Although preemptible RCU is plenty reliable if you are running only a few thousand servers (and maybe even a few tens of thousands), it has some improving to do before I will be comfortable recommending its use in a large-scale datacenters. And yes, I know about Android deployments. But those devices tend to spend very little time in the kernel, in fact, many of them tend to spend very little time powered up. Plus they tend to have relatively few CPUs, at least by 2020s standards. So it takes a rather large number of Android devices to impose the same stress on the kernel that is imposed by a single mid-sized server. And we are working on making preemptible RCU more reliable. One nice change over the past 5-10 years is that more people are getting serious about digging into the RCU code, testing it, and reporting and fixing the resulting bugs. I am also continuing to make rcutorture more vicious, and of course I am greatly helped by the easier availability of hardware with which to test RCU. If this level of activity continues for another five years, then maybe preemptible RCU will be ready for large datacenter deployments. But I am guessing that you had something in mind in addition to code consolidation. Thanx, Paul