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 1E072C4167B for ; Tue, 5 Dec 2023 01:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 675F26B00A1; Mon, 4 Dec 2023 20:01:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FF056B00A3; Mon, 4 Dec 2023 20:01:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 478776B00A4; Mon, 4 Dec 2023 20:01:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 32AFB6B00A1 for ; Mon, 4 Dec 2023 20:01:32 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F044E16047E for ; Tue, 5 Dec 2023 01:01:31 +0000 (UTC) X-FDA: 81530961582.10.F8F694B Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf11.hostedemail.com (Postfix) with ESMTP id 8422340019 for ; Tue, 5 Dec 2023 01:01:28 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eayp4XkN; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of "SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=7QCX=HQ=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=1701738089; 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=3Lbk4HWmSAmiIgyNxsBgCTiloBrK6Na2ZkN+fM1shHA=; b=Dmybyo91MlkDAMIi3Kas+a6qgvogRq5rpVD5tvEc3xrrntBDi2nsEEpwMRprU4KSPITiqb X4FEaOwITX904ahfp3DvtmlYYnjF59nU4EBBQlEO3FJJPVVPgKzuXsrglaye6UImXvvDN2 6mIABnKcpT9RCWy/SpeKH7XpSCBiiLk= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eayp4XkN; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of "SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=7QCX=HQ=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701738089; a=rsa-sha256; cv=none; b=JcoGxdvvwRTwtFylyMkUW39bD3Qxrp9LKRWt+jMOUpbykaW9J1E2D9CzqbUIJ2+8J4x9z8 ApJft1iwuF2i3aUIHb8nSTEqYuSvg9XbWMyabYBt6pP6rsvnXTdegtAu959sRlQfp+tRga mRRCGTwkows2DchO1M0JIUSaUsAXiyQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id EB2F8CE134B; Tue, 5 Dec 2023 01:01:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27B7FC433C7; Tue, 5 Dec 2023 01:01:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701738084; bh=87+opENFHVxb4r8vWzTfPZbzUsfLV0xi8qw1aguD08c=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=eayp4XkNfs4A+5kiHvcgyT8erJMahBuKlXkjRI+zG9MhS/KzQOEAR4XnJ6MXkOgoZ 5fOITSZSmSGMeDXUrsaWreX4882T8jzHitfh5M0S/B8YTyFtVxQjw8UFFYgYwCW5y7 SHsNo7cCman4adEx0/NH/V7+Lg3GKcNw9JDZ6CA/3x8bpViRjuvjCBjYhzCLPGjZOH n9fJYT7SUehfCMbcw44fXoOQ9EMn5EbRWzcSP4kGP+DAc4xMR1FAqQT19x5IjCsU7z kGSz8tPdAidqknvhfhpzm5etbx9dzc4pFnXeB9T3i3vcNQyP5sNevP6oy6blq1RWgb DQKIkMWmh2oJw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B1A76CE1147; Mon, 4 Dec 2023 17:01:21 -0800 (PST) Date: Mon, 4 Dec 2023 17:01:21 -0800 From: "Paul E. McKenney" To: Thomas Gleixner Cc: Steven Rostedt , Ankur Arora , linux-kernel@vger.kernel.org, peterz@infradead.org, torvalds@linux-foundation.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, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, Simon Horman , Julian Anastasov , Alexei Starovoitov , Daniel Borkmann Subject: Re: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT Message-ID: Reply-To: paulmck@kernel.org References: <87wmu2ywrk.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wmu2ywrk.ffs@tglx> X-Rspamd-Queue-Id: 8422340019 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 9exjez9c6m8zgsmddac95egpdxwpm9mw X-HE-Tag: 1701738088-738215 X-HE-Meta: U2FsdGVkX19oviPH2nHQyapTaRpzkMuOyO+oXOybTkf4E8fD8ipE/sW28ix7wD2YXbGhZlnkuav8NBVqKhMTGNAZMZu5IPWoq/MYa2iJstPFt0smc4M4Y8He84osE2bydDniUI0ekIk/JMVWuBdqhTatIAcKcelym6O0s7COcyetjQ1dif+PvmOoVos/L8qvphpnxcdhUNq4jMUxEuVU2HQ0DvI1TrDg3q76RkpP8ROHo+MRsqRvbleRpH2Mvr2SuDvY6XE5b7ROWFd/MEJnClPTLUEVOyA05lx1VjZj/NbPzDT9hfnGzeU9tAxmogeNcgbFPUg6cHaGEth9Ft+3/IJIPrrP9bj+1rqCZJFlfUJ6WMa6lJlKBrGTUB2EjwjuGgB3Dgs9usnb8DlwDAZJEEHR2Nyag5d0QokUkVe7fxFBpzZOTQROFTATcr63SxGuoLj6I2euiKlVbIyYwZYcamvNZEgGkDViQStFDcFto7i9YqU7BQPLlr5kOv0WvZd3ONHrNbiAfqYuzkm0Br+KxWM2IxKoOpU/rv0/YGvNVdyhaUMZM2Ed2cobjEY0f4jWZ19P34KLZAVZHxVZsGSiwfUrQojJXV9ibsisvYxM6KhXuPL6SVxxB/hvABb2jz/ffDwtHp/YiLmSiOr/KSxqg+8Qc5BtRBtVGCjBGWMlM++EJixBt+fOBYMdejPM5XasDbBJVf1KlLkuMc7jGOYnOmRHCcOtwmJR0QFbYCSeZ7RrtaZedCUA5kAQQzFj/Wx5PsUefPGY/4EvXujlZqcnU5PvMeXAry11AkxmwSKZlJOHm9ecxZeFWQy1bpPT4XlYYTlxsxQmWOn8gxKH6A7/OOxYgZB2P1ZFw3WdHKxB/tQllUvHcAqfrkFm/mfBgCmsEPxKC+SoJNXQe/t8OBEHA8bo7qnheNPQUk/5iEinbZumF+pS1gG2zfUTnEJKM1v4QxCeaG9K5mqWYGNcox6 ak6W6t3o DWl8/1oOaXZnJB8B1MkW+XMlGMUOd5lKOMFavvKHoMLcgMscLLKdkmz+pdY0pyRYCAWsLRHcjEB21R3GsGq/aMwV6MVBHtb/pIkiGrOMNVulxur68hcNFz8c4tcDEuKrXP+emkEqxk1Fkld6wqJWq4Rn9bIeaeG7t0lgKZBXz8jpu8yAI58lBbL7w3ao57btKZ8kqDP008s87RcbiggNafwbGzta1GE95SDPYGMK4hTPRa/+n8BeX+4xoP7TfLdBHybPPbP4z9phF6EBI3X2Wx4Enrdm5RChHGtPXNj2foXpPGrHdK4SYaF1cxOHZYzDwna6+AiYUdk+65sGy1OVgELcCJG8WjDDuVsvUw0HYulHJdccC+OoYcqfKNFNyF9d9Xjw3eG9U8Ewkh8aMERlV3yQ7yDMesS8sRK03Fg0T0Pl2vhLqJ6kyVXWFFt6CslTlw6tYKLg2HKbdS5wL4OeDwOoQMcZJjnN9hyuU/+NVgHOhAWrJySgajAn+Y4a7zFwtkx8HI8xMYFNFrOsQclhWudg40eWgP32H4hmwJXrL3Zok8ie1Cugi8g4aR1vag4vcYKivgePajxJZbd4ksQPdde7wk7gqEbuzT9vaU9gAvVN7Ee7Pru+UJz09wdaRjBLUCl98 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 Tue, Nov 28, 2023 at 11:53:19AM +0100, Thomas Gleixner wrote: > Paul! > > On Tue, Nov 21 2023 at 07:19, Paul E. McKenney wrote: > > On Tue, Nov 21, 2023 at 10:00:59AM -0500, Steven Rostedt wrote: > >> Right now, the use of cond_resched() is basically a whack-a-mole game where > >> we need to whack all the mole loops with the cond_resched() hammer. As > >> Thomas said, this is backwards. It makes more sense to just not preempt in > >> areas that can cause pain (like holding a mutex or in an RCU critical > >> section), but still have the general kernel be fully preemptable. > > > > Which is quite true, but that whack-a-mole game can be ended without > > getting rid of build-time selection of the preemption model. Also, > > that whack-a-mole game can be ended without eliminating all calls to > > cond_resched(). > > Which calls to cond_resched() should not be eliminated? The ones which, if eliminated, will result in excessive latencies. This question is going to take some time to answer. One type of potential issue is where the cond_resched() precedes something like mutex_lock(), where that mutex_lock() takes the fast path and preemption follows shortly thereafter. It would clearly have been better to have preempted before acquisition. Another is the aforementioned situations where removing the cond_resched() increases latency. Yes, capping the preemption latency is a wonderful thing, and the people I chatted with are all for that, but it is only natural that there would be a corresponding level of concern about the cases where removing the cond_resched() calls increases latency. There might be others as well. These are the possibilities that have come up thus far. > They all suck and keeping some of them is just counterproductive as > again people will sprinkle them all over the place for the very wrong > reasons. Yes, but do they suck enough and are they counterproductive enough to be useful and necessary? ;-) > > Additionally, if the end goal is to be fully preemptible as in eventually > > eliminating lazy preemption, you have a lot more convincing to do. > > That's absolutely not the case. Even RT uses the lazy mode to prevent > overeager preemption for non RT tasks. OK, that is very good to hear. > The whole point of the exercise is to keep the kernel always fully > preemptible, but only enforce the immediate preemption at the next > possible preemption point when necessary. > > The decision when it is necessary is made by the scheduler and not > delegated to the whim of cond/might_resched() placement. I am not arguing that the developer placing a given cond_resched() always knows best, but you have some work to do to convince me that the scheduler always knows best. > That is serving both worlds best IMO: > > 1) LAZY preemption prevents the negative side effects of overeager > preemption, aka. lock contention and pointless context switching. > > The whole thing behaves like a NONE kernel unless there are > real-time tasks or a task did not comply to the lazy request within > a given time. Almost, give or take the potential issues called out above for the possible downsides of removing all of the cond_resched() invocations. > 2) It does not prevent the scheduler from making decisions to preempt > at the next possible preemption point in order to get some > important computation on the CPU. > > A NONE kernel sucks vs. any sporadic [real-time] task. Just run > NONE and watch the latencies. The latencies are determined by the > interrupted context, the placement of the cond_resched() call and > the length of the loop which is running. > > People have complained about that and the only way out for them is > to switch to VOLUNTARY or FULL preemption and thereby paying the > price for overeager preemption. > > A price which you don't want to pay for good reasons but at the > same time you care about latencies in some aspects and the only > answer you have for that is cond_resched() or similar which is not > an answer at all. All good points, but none of them are in conflict with the possibility of leaving some cond_resched() calls behind if they ar needed. > 3) Looking at the initial problem Ankur was trying to solve there is > absolutely no acceptable solution to solve that unless you think > that the semantically invers 'allow_preempt()/disallow_preempt()' > is anywhere near acceptable. I am not arguing for allow_preempt()/disallow_preempt(), so for that argument, you need to find someone else to argue with. ;-) Thanx, Paul