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 60718C61D98 for ; Wed, 22 Nov 2023 00:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63C046B050E; Tue, 21 Nov 2023 19:01:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C48E6B0512; Tue, 21 Nov 2023 19:01:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 466366B0518; Tue, 21 Nov 2023 19:01:33 -0500 (EST) 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 319636B050E for ; Tue, 21 Nov 2023 19:01:33 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 11190B5D0B for ; Wed, 22 Nov 2023 00:01:33 +0000 (UTC) X-FDA: 81483636066.20.F3CFF4A Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf13.hostedemail.com (Postfix) with ESMTP id 923652002B for ; Wed, 22 Nov 2023 00:01:30 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=m856fzwa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.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=1700611291; 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=tmKrjb/OcgJIchT32Rezmo+w4lQ3sxijmuNMBaZQomA=; b=pB4E/740mkLhMTIG7k3FifyALU4/nSWDpRWkZwNjIDRQYDj5jB9ulMlpilqtJoVZzMz0p6 uzBlQId4yiIUc5PRv1GynMbx+lDglq+3Oh0PQEGNQELCO7ZD13P9pg70Nu2KyTQ8e22uvB 5s2omYIcSqWbzDW1wU7IDmRLZnhxJMI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=m856fzwa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.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=1700611291; a=rsa-sha256; cv=none; b=fUvUUfA94380KKNB2PnK/NExa7Uw6LR6VB8o3HWvKbCGhSimm/L0VpMYGLDPoS2X0b8NGn c0hVuO+AzoT1hU9qKeSrlw4SsTPZJWzglYU7/nRwVCr0QQ7McuMSQ/bG8hTusUTjCah8uR zg3pS+6oKu+kEoqXWiIUMexL6gfkKek= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 41144CE1E05; Wed, 22 Nov 2023 00:01:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 988D4C433C8; Wed, 22 Nov 2023 00:01:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700611284; bh=SQLOLBDlMnBI/mq/51HaPLasJW//OWPjVkbjwRsgkDM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=m856fzwao6VC1b7rfMpHRHSwFRBn/HzA0R6GPpPfTRdeX7+IUoayUxL4OKGE7LETf duVfYQOhpHLCp6GgodseTyNakLsR3hBmzXm+BHjQ5O9JuGuFn7/bot4Goy/hHsdkK0 OBBfUE6vhVacg36l5pHklboO+uTdYAEuedRQ3tqw9U/xF/zW7HERoka4z28vpo4H1k 60BNPJHTQah3ZUXTYsCYkX4oSA63PkeKmcj3kNNy3FSHrXHMNDQSoPBCfpdeub+ZWg mNmZNfzisfubfYp/KOAzFOLlgcf9VHKreihLjT8Vlm6mTsXS6mnkyZpSWWJ9Hs9aV5 zPt+h9maJR/Tg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 1E650CE0ACF; Tue, 21 Nov 2023 16:01:24 -0800 (PST) Date: Tue, 21 Nov 2023 16:01:24 -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: <0d6a8e80-c89b-4ded-8de1-8c946874f787@paulmck-laptop> Reply-To: paulmck@kernel.org References: <2027da00-273d-41cf-b9e7-460776181083@paulmck-laptop> <87lear4wj6.fsf@oracle.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231121175209.1d7ec202@gandalf.local.home> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 923652002B X-Stat-Signature: 7y7pextc9o4tepj7hhr6ec38g1ukrope X-Rspam-User: X-HE-Tag: 1700611290-677579 X-HE-Meta: U2FsdGVkX1997PSxnTp8uc0ubHZtgu2cCqdi41kK5FmmjjcNhsV67ee4lJi+2QJ223lYRZ4q4KMwADJf5wPzaGoCOhl9NGdqGClwueV/9GvaZI0bIh9LtsTSZM1l5vsTsnjLy7zzHus380SzuNyZFADu0UWPJbwR5jAr7lcj26EyOmHyYnAgAdsnrZsrSZzBe1ixPQFj73j4to1CpQ4uOATs5rWAyMOCNVwdgiZrEWQ/UjMKqS1ieqUortYr5iBiBneWQIIKTVAYWWfaz/1EkVbjkTa9oVYLfRXTCx0r5u5ENhpBmW+t3S7LpVodpt53jGTuDqY9aYdnuJaIPiYDV/lSgZfL9qDSLkZlhhaDaon/MjRi4cVpErxkDn+YylP/8ruA4j+GL1aL4nXclGOl1Ff/3xnN5uzdRN1yr2hHSDnIvjYT0m6YJ7QG84cQziI5ZMXSqdrXUb3MXjp65MXBtzSJ8ccJRXiqAXAjSQfm516zZ5BnrDG4WicgHBhaczJ+6d04vwNao5/Z1p9X2pLRzDfn4HP2rNU3u9jIa28x4U02k1K3zz6MIFl0FiiL2vzRbj01vKfzVMwPD0Q65HKoR2DkzSNipGhhbYUzhovTHUofAbhP7BXXsb0I6LtojvrrFHxmnSXi4b7DJ3iCRCSUE+aCPrdpc1HXe5D6FAuWAXF8nF4PFo1VBqnc9/OD9ntNMeAy9FHJESpWFnP3y/BODUIMRSRP7CImCls+cZu2KQFZ5obAC/BgJsge2VVMhYpAQFm2a8Ayd2fZUysI5nJA3k2/PsuTxWa3ZQeV7gZAsBYNgsMjAHdANCbRU526lXfaAh+QGxsxWa7S9IXxcP922BQe4jd7RCh2Ra2lUdxzB+U5tETVUeI7CPiCGG+Qg0UslQ6qqSUnS0EgryXx5gGal+Ma1kxIyx9jgAdPVbxqrmgGrFCh+TlG9KratiKbn7XlW7lfaCSxsDv6OUH1+ax AZaSD9JL 1uE2x+zyscnRfXZuTVXrd+iVS4E4NkL+fOO34W7SJS9j2U91h1/uO2x+rWRGvEKeLDwpjNXSWj58u2ygNaGzN0SDkwF0o1q8uZNzJm9fTQcR2QNRV3ihTfLSpZIBKYwK0XYV5Rjp2BiwE5+znsPEg1+GkA8YQj8JuSDXBUTegsynlqDFtyzfDhwTGJgmQWV9rG6rMQKtsuhSv7tb4kecjMoDI20h898ukZ1fvCkUX2L5nJ2SBMI7Cso2uBqsI191O25ajGQ7O3PwDREXbT4BiSGXzQmsIAo4qcFNTMIckopVkyXdNSg64WGItcYK9d7g+eLxSuI0D0ekuLmNNF7fkCCRmUiKt3beCjB97pIbasloGPXmaxXWj92+OXJeRTDY7umXfMfqYpQeHgiFgIQTk4cdh3kjKIlwgtKgynu6a28nsDrvKz/fQ10uAuFkq6iV9fEXVKbL/itFEPIjFMnx7ziDdd2I1fUg6yZYgoEgyqYJBNNjVB5u7+QyoJ89kMESfPyj5Y1aqfIQQDoArHszS0LKa7YnEkmlNXBJxhFa+REqbqQDdnnCtykZUVN956NnrPVO+46ZxtZJvlxby2PHnbFZwcmFOgDEh7DZADZUjyJHez4JqlxI10u6b1sMXZYgRFLTENcoz7rO+xu0= 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 05:52:09PM -0500, Steven Rostedt wrote: > On Tue, 21 Nov 2023 14:26:33 -0800 > "Paul E. McKenney" wrote: > > > On Tue, Nov 21, 2023 at 04:38:34PM -0500, Steven Rostedt wrote: > > > On Tue, 21 Nov 2023 13:14:16 -0800 > > > "Paul E. McKenney" wrote: > > > > > > > On Tue, Nov 21, 2023 at 09:30:49PM +0100, Peter Zijlstra wrote: > > > > > On Tue, Nov 21, 2023 at 11:25:18AM -0800, Paul E. McKenney wrote: > > > > > > #define preempt_enable() \ > > > > > > do { \ > > > > > > barrier(); \ > > > > > > if (!IS_ENABLED(CONFIG_PREEMPT_RCU) && raw_cpu_read(rcu_data.rcu_urgent_qs) && \ > > > > > > (preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK | HARDIRQ_MASK | NMI_MASK) == PREEMPT_OFFSET) && > > > > > > !irqs_disabled()) \ > > > > > > Could we make the above an else case of the below if ? > > > > Wouldn't that cause the above preempt_count() test to always fail? > > preempt_count_dec_and_test() returns true if preempt_count() is zero, which > happens only if NEED_RESCHED is set, and the rest of preempt_count() is not > set. (NEED_RESCHED bit in preempt_count() is really the inverse of > NEED_RESCHED). Do we need to call rcu_all_qs() when we call the scheduler? > Isn't scheduling a quiescent state for most RCU flavors? > > I thought this was to help move along the quiescent states without added > cond_resched() around, which has: > > int __sched __cond_resched(void) > { > if (should_resched(0)) { > preempt_schedule_common(); > return 1; > } > /* > * In preemptible kernels, ->rcu_read_lock_nesting tells the tick > * whether the current CPU is in an RCU read-side critical section, > * so the tick can report quiescent states even for CPUs looping > * in kernel context. In contrast, in non-preemptible kernels, > * RCU readers leave no in-memory hints, which means that CPU-bound > * processes executing in kernel context might never report an > * RCU quiescent state. Therefore, the following code causes > * cond_resched() to report a quiescent state, but only when RCU > * is in urgent need of one. > */ > #ifndef CONFIG_PREEMPT_RCU > rcu_all_qs(); > #endif > return 0; > } > > Where if we schedule, we don't call rcu_all_qs(). True enough, but in this __cond_resched() case we know that we are in an RCU quiescent state regardless of what should_resched() says. In contrast, with preempt_enable(), we are only in a quiescent state if __preempt_count_dec_and_test() returns true, and even then only if interrupts are enabled. > 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? Thanx, Paul