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 E06E1C61D97 for ; Wed, 22 Nov 2023 01:09:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77D576B0539; Tue, 21 Nov 2023 20:09:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 72D306B053F; Tue, 21 Nov 2023 20:09:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CE4D6B0540; Tue, 21 Nov 2023 20:09:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4A38C6B0539 for ; Tue, 21 Nov 2023 20:09:40 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1037980A91 for ; Wed, 22 Nov 2023 01:09:40 +0000 (UTC) X-FDA: 81483807720.17.A930ABD Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id A51A2120019 for ; Wed, 22 Nov 2023 01:09:37 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dDLSkBmp; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of "SRS0=MCJj=HD=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=MCJj=HD=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=1700615378; 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=eg/lWZ5QTrQkA7SZqLx2eRWigw3oxuN4qYo73THjWE4=; b=abxa0iPpLRLSCBfj5QTi9sHSjbn1SEf2FUkFeoOVayhpdzz671kBAUqLrLcv1cIFIOHuVk 4QBfm1QGhVPELzmEf28H1kVrT1rRz9FmOXlC1zC6DNzshlt7ZxuZgpZGY3ZyPveNODHwaq z0asfjFDS5yZ2yCFj7ZYRf4KGzUPJ/s= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dDLSkBmp; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of "SRS0=MCJj=HD=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=MCJj=HD=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700615378; a=rsa-sha256; cv=none; b=SPgpaBuq3OxpD7mkbqMITS4iutxX/bL+ecN8ITJIizqicLAg7zK0NC2pPmiPkdVxg6eCMW bc7fTG8GYqvcprWaLK7RWQmX6d5GKAiOxsKKF8a9tpPwAWMFmmyUpvxVTw3/lLhHTLY3L+ sCo2tpW0TYuFp04uiB+ZJdrVhjK4cH8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 59815CE1BD3; Wed, 22 Nov 2023 01:09:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C89FC433C7; Wed, 22 Nov 2023 01:09:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700615372; bh=qx4+zB74OcXNmjhoM86H8BT/pDj/mX4jQpnt9gfScjM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=dDLSkBmpkz4uDUA4xFFvrcZUoTdP6LC7E7QVoaqUrUD5VhwNHjt/w9MEi/E1BGAu8 zYFmhq1OLFjUogIyk7RP7V3//peW3G/FohvZNuuCtJ8I62+ZLsb18WfthOzK67v4jt jARxSn90i78rkGWvsjEgWToNGaSNIdYtzZrkBP/oIwrF5PQuakLuaqFVvxS8QiASMN 8G082OsZrMXsIjZAyW9O3PPhx+XXTjqA1/jNcfffYWE1cSMuzytkYqBfE9Pa4/cQRy lo+QiC66wFKRAHGgwjZnDupaWbaiDYk+i45HT/Dtz1qrGBuEhlqLewBve7WVP5YnO6 g3EAqbJfZjoOw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 23A3FCE0ACF; Tue, 21 Nov 2023 17:09:32 -0800 (PST) Date: Tue, 21 Nov 2023 17:09:32 -0800 From: "Paul E. McKenney" To: Steven Rostedt Cc: Peter Zijlstra , Ankur Arora , linux-kernel@vger.kernel.org, tglx@linutronix.de, 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 Subject: Re: [RFC PATCH 48/86] rcu: handle quiescent states for PREEMPT_RCU=n Message-ID: Reply-To: paulmck@kernel.org References: <46a4c47a-ba1c-4776-a6f8-6c2146cbdd0d@paulmck-laptop> <31d50051-e42c-4ef2-a1ac-e45370c3752e@paulmck-laptop> <20231121203049.GN8262@noisy.programming.kicks-ass.net> <1cdbb0f6-9078-4023-bf37-8d826ca0c711@paulmck-laptop> <20231121163834.571abb52@gandalf.local.home> <4605b4f4-8a2b-4653-b684-9c696c36ebd0@paulmck-laptop> <20231121175209.1d7ec202@gandalf.local.home> <0d6a8e80-c89b-4ded-8de1-8c946874f787@paulmck-laptop> <20231121191232.630222d3@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231121191232.630222d3@gandalf.local.home> X-Rspam-User: X-Stat-Signature: 6oygr1kyj5boeaxzpd98hpie1hxwfiaw X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A51A2120019 X-HE-Tag: 1700615377-903553 X-HE-Meta: U2FsdGVkX1807CjCkeZehcW9o0RxsM69HUmbiYyh9OmlMDrwXk64GkqY5yF5lVE/v6K7BPr3tSqQpUyr6S7utVcBrBIx+pzSwXrKBQ6ae+2B+A3TghVwkpco2MqFm9DufTffT9+/5EKmZ6Mqb4AzGscQLF4ygbAWB5LhBkuZC5gez3dQwO94eq3fcacjF4Ua48eBfMZ5p1iQ4TqXnhzQxPFXBgHsgObEIvMldP9ggCmRktFV0NSBpLt3UApbLHGeLpflSUp9LZppqR4CjTLqUQnsF8vcwjbs3RRGzUw6n7KgrO7fReqzLc4pw1pAlgwCa0F3i5BuqjwuYkAQYVaa72A7QzZTIsgT7iKbhyT8FN50TpdbzYM8s6HnbOWve+FHsa5aI5Y8pmFGKbM7IlEJwkoi1J9A4Lim/1s9j3sUyZtQTd8wIQ3RcCYVlXUk3EB5bxaP7h96j19h+Y9lUxhPxucaPceNLsR8NfpFaP+wV+iJHyPB+nhtwZ9SUHpZCfSoXmrVBibSFSVn0o/W+P2zGy1tUBdfflHzXQqv52YezgE8n0fchQIlm7g7uw6T+zykonRfp8/FLtBrtP9SD0f2KCdAmWubaRxQRCbi3Q+G8r3DAcPxtSxOj6utqBNtmGARWklCfKy41a6fgGguAGQplR6lONPO9R0f8w5VoS/KUG1UbrsLfost2rORY0viIJT78rDqxrcpGJL+1HTn/hKxKB3H7EIBJNazkUN1m1riZe8v2uXzjFI7Pbw5xjxqSsD9NNuwy6zlb1k1n0fXy5fJ17kcu2sdp7M6P2jrOE7gQLdp2v7zl09DiiLDNvUqywi9NRt3algpELqZnahrFqXAKNVlCFRaUaTGzfD0CvBuLamhaRTkIVUHg7BWf16Phw4mrnRrk2lpCzcW0k5xdFogqcLqft8YAWhe4GSgQ5RcAe99dVEGkOXCgnPWQOq1XTjihh9VUiBnyxheEyUaCKo Y9awgRGC 9aHGBO4cGIvv80NIO0M6RzXkpT4nvPUvIE2O6EvvypoYzburjg0JCLnLcDXZX1PvS/kYqqitUlb2aI0z5KxVM/ezuwrr8CXLVGHaP3lt/fx0vZq30qgNNDY3ziQaYrTKlZqAH3Uqn5yyaeQS22IAhGLWQlQq41E5mrkPjJeYRTKjqdu46N5418eZDNGUsIY+k2wmX+T0h2vVcclia08OfoE4G8zvX3BXfPPrPKVdfOb1HI/dUxihD6X9oYKuZrxIfALCcFlgzrJ2yfCH2y8NHTJeCbm4vUYpC6syzhUJbV5IJmXZQL+23wp1iBvLht/2EQUReLe8UotfFMOL7dUhHUBkt/PQNxuZbLto9woltrJPuiam/2GXC/i8BK4QVQzjoVQxTUDx2udFGDOIReck6L7HZgcn2kFUCO0yW1bK/ipHuxijljMvu/qbx6KKhhFv/607g/Munn8IhCweyPc7pn4lrg1ihXDV/UdzGKlLTrNu/o9Mdab125wbURGu74kZJNaLow4eDdeKH37UvBLGEYKyA3+3on1sFQ3T/4VAxQoSb8JDKbAqfzlP914claUycOgd+MoaTXSPW2El5xVMihlfJ6EsFEQSooM+itpTYvoLJ9WY3/wujJl68xv+c7f+JQxHZPmtRuYjUmhA= 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 21, 2023 at 07:12:32PM -0500, Steven Rostedt wrote: > On Tue, 21 Nov 2023 16:01:24 -0800 > "Paul E. McKenney" wrote: > > > > > > I stand by that being in the else statement. It looks like that would keep > > > the previous work flow. > > > > Ah, because PREEMPT_NEED_RESCHED is zero when we need to reschedule, > > so that when __preempt_count_dec_and_test() returns false, we might > > still be in an RCU quiescent state in the case where there was no need > > to reschedule. Good point! > > > > In which case... > > > > #define preempt_enable() \ > > do { \ > > barrier(); \ > > if (unlikely(preempt_count_dec_and_test())) \ > > __preempt_schedule(); \ > > else if (!sched_feat(FORCE_PREEMPT) && \ > > (preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK | HARDIRQ_MASK | NMI_MASK) == PREEMPT_OFFSET) && \ > > !irqs_disabled()) \ > > ) \ > > rcu_all_qs(); \ > > } while (0) > > > > Keeping rcu_all_qs() pretty much as is. Or some or all of the "else if" > > condition could be pushed down into rcu_all_qs(), depending on whether > > Peter's objection was call-site object code size, execution path length, > > or both. ;-) > > > > If the objection is both call-site object code size and execution path > > length, then maybe all but the preempt_count() check should be pushed > > into rcu_all_qs(). > > > > Was that what you had in mind, or am I missing your point? > > Yes, that is what I had in mind. > > Should we also keep the !IS_ENABLED(CONFIG_PREEMPT_RCU) check, which makes > the entire thing optimized out when PREEMPT_RCU is enabled? I substituted the !sched_feat(FORCE_PREEMPT) for this because as I understand it, sites currently using CONFIG_PREEMPT_DYNAMIC=y (which is the default) and booting with preempt=none will currently have their grace periods helped by cond_resched(), so likely also need help, perhaps also from preempt_enable(). Thanx, Paul