All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: John Ogness <john.ogness@linutronix.de>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, rostedt@goodmis.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH RFC v2 rcu 1/8] srcu: Convert ->srcu_lock_count and ->srcu_unlock_count to atomic
Date: Sat, 1 Oct 2022 09:51:52 -0700	[thread overview]
Message-ID: <20221001165152.GO4196@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <87wn9k7g4o.fsf@jogness.linutronix.de>

On Fri, Sep 30, 2022 at 10:43:43PM +0206, John Ogness wrote:
> On 2022-09-30, "Paul E. McKenney" <paulmck@kernel.org> wrote:
> >> > -	this_cpu_inc(ssp->sda->srcu_lock_count[idx]);
> >> > +	this_cpu_inc(ssp->sda->srcu_lock_count[idx].counter);
> >> 
> >> Is there any particular reason that you are directly modifying
> >> @counter instead of raw_cpu_ptr()+atomic_long_inc() that do you in
> >> __srcu_read_lock_nmisafe() of patch 2?
> >
> > Performance.  From what I can see, this_cpu_inc() is way faster than
> > atomic_long_inc() on x86 and s390.  Maybe also on loongarch.  No idea
> > on arm64.
> 
> Yeah, that's what I figured. I just wanted to make sure.
> 
> FWIW, the rest of the series looks pretty straight forward to me.

Thank you for looking it over!  The updated patch is shown below.
The full series is in -rcu at branch srcunmisafe.2022.09.30a.  Feel free
to pull it into your printk() series if that makes things easier for you.

							Thanx, Paul

------------------------------------------------------------------------

commit 24511d0b754db760d4e1a08fc48a180f6a5a948b
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Thu Sep 15 12:09:30 2022 -0700

    srcu: Convert ->srcu_lock_count and ->srcu_unlock_count to atomic
    
    NMI-safe variants of srcu_read_lock() and srcu_read_unlock() are needed
    by printk(), which on many architectures entails read-modify-write
    atomic operations.  This commit prepares Tree SRCU for this change by
    making both ->srcu_lock_count and ->srcu_unlock_count by atomic_long_t.
    
    [ paulmck: Apply feedback from John Ogness. ]
    
    Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/
    
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Ogness <john.ogness@linutronix.de>
    Cc: Petr Mladek <pmladek@suse.com>

diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
index e3014319d1ad..0c4eca07d78d 100644
--- a/include/linux/srcutree.h
+++ b/include/linux/srcutree.h
@@ -23,8 +23,8 @@ struct srcu_struct;
  */
 struct srcu_data {
 	/* Read-side state. */
-	unsigned long srcu_lock_count[2];	/* Locks per CPU. */
-	unsigned long srcu_unlock_count[2];	/* Unlocks per CPU. */
+	atomic_long_t srcu_lock_count[2];	/* Locks per CPU. */
+	atomic_long_t srcu_unlock_count[2];	/* Unlocks per CPU. */
 
 	/* Update-side state. */
 	spinlock_t __private lock ____cacheline_internodealigned_in_smp;
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 1c304fec89c0..25e9458da6a2 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -417,7 +417,7 @@ static unsigned long srcu_readers_lock_idx(struct srcu_struct *ssp, int idx)
 	for_each_possible_cpu(cpu) {
 		struct srcu_data *cpuc = per_cpu_ptr(ssp->sda, cpu);
 
-		sum += READ_ONCE(cpuc->srcu_lock_count[idx]);
+		sum += atomic_long_read(&cpuc->srcu_lock_count[idx]);
 	}
 	return sum;
 }
@@ -434,7 +434,7 @@ static unsigned long srcu_readers_unlock_idx(struct srcu_struct *ssp, int idx)
 	for_each_possible_cpu(cpu) {
 		struct srcu_data *cpuc = per_cpu_ptr(ssp->sda, cpu);
 
-		sum += READ_ONCE(cpuc->srcu_unlock_count[idx]);
+		sum += atomic_long_read(&cpuc->srcu_unlock_count[idx]);
 	}
 	return sum;
 }
@@ -503,10 +503,10 @@ static bool srcu_readers_active(struct srcu_struct *ssp)
 	for_each_possible_cpu(cpu) {
 		struct srcu_data *cpuc = per_cpu_ptr(ssp->sda, cpu);
 
-		sum += READ_ONCE(cpuc->srcu_lock_count[0]);
-		sum += READ_ONCE(cpuc->srcu_lock_count[1]);
-		sum -= READ_ONCE(cpuc->srcu_unlock_count[0]);
-		sum -= READ_ONCE(cpuc->srcu_unlock_count[1]);
+		sum += atomic_long_read(&cpuc->srcu_lock_count[0]);
+		sum += atomic_long_read(&cpuc->srcu_lock_count[1]);
+		sum -= atomic_long_read(&cpuc->srcu_unlock_count[0]);
+		sum -= atomic_long_read(&cpuc->srcu_unlock_count[1]);
 	}
 	return sum;
 }
@@ -636,7 +636,7 @@ int __srcu_read_lock(struct srcu_struct *ssp)
 	int idx;
 
 	idx = READ_ONCE(ssp->srcu_idx) & 0x1;
-	this_cpu_inc(ssp->sda->srcu_lock_count[idx]);
+	this_cpu_inc(ssp->sda->srcu_lock_count[idx].counter);
 	smp_mb(); /* B */  /* Avoid leaking the critical section. */
 	return idx;
 }
@@ -650,7 +650,7 @@ EXPORT_SYMBOL_GPL(__srcu_read_lock);
 void __srcu_read_unlock(struct srcu_struct *ssp, int idx)
 {
 	smp_mb(); /* C */  /* Avoid leaking the critical section. */
-	this_cpu_inc(ssp->sda->srcu_unlock_count[idx]);
+	this_cpu_inc(ssp->sda->srcu_unlock_count[idx].counter);
 }
 EXPORT_SYMBOL_GPL(__srcu_read_unlock);
 
@@ -1687,8 +1687,8 @@ void srcu_torture_stats_print(struct srcu_struct *ssp, char *tt, char *tf)
 			struct srcu_data *sdp;
 
 			sdp = per_cpu_ptr(ssp->sda, cpu);
-			u0 = data_race(sdp->srcu_unlock_count[!idx]);
-			u1 = data_race(sdp->srcu_unlock_count[idx]);
+			u0 = data_race(atomic_long_read(&sdp->srcu_unlock_count[!idx]));
+			u1 = data_race(atomic_long_read(&sdp->srcu_unlock_count[idx]));
 
 			/*
 			 * Make sure that a lock is always counted if the corresponding
@@ -1696,8 +1696,8 @@ void srcu_torture_stats_print(struct srcu_struct *ssp, char *tt, char *tf)
 			 */
 			smp_rmb();
 
-			l0 = data_race(sdp->srcu_lock_count[!idx]);
-			l1 = data_race(sdp->srcu_lock_count[idx]);
+			l0 = data_race(atomic_long_read(&sdp->srcu_lock_count[!idx]));
+			l1 = data_race(atomic_long_read(&sdp->srcu_lock_count[idx]));
 
 			c0 = l0 - u0;
 			c1 = l1 - u1;

  reply	other threads:[~2022-10-01 16:52 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 14:46 [PATCH rcu 0/4] NMI-safe SRCU reader API Paul E. McKenney
2022-09-21 14:46 ` [PATCH RFC rcu 1/4] srcu: Convert ->srcu_lock_count and ->srcu_unlock_count to atomic Paul E. McKenney
2022-09-21 14:46 ` [PATCH RFC rcu 2/4] srcu: Create and srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe() Paul E. McKenney
2022-09-21 14:46 ` [PATCH RFC rcu 3/4] srcu: Check for consistent per-CPU per-srcu_struct NMI safety Paul E. McKenney
2022-09-21 14:46 ` [PATCH RFC rcu 4/4] srcu: Check for consistent global " Paul E. McKenney
2022-09-29 18:07 ` [PATCH v2 rcu 0/8] NMI-safe SRCU reader API Paul E. McKenney
2022-09-29 18:07   ` [PATCH RFC v2 rcu 1/8] srcu: Convert ->srcu_lock_count and ->srcu_unlock_count to atomic Paul E. McKenney
2022-09-30 15:02     ` John Ogness
2022-09-30 15:35       ` Paul E. McKenney
2022-09-30 20:37         ` John Ogness
2022-10-01 16:51           ` Paul E. McKenney [this message]
2022-09-29 18:07   ` [PATCH RFC v2 rcu 2/8] srcu: Create an srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe() Paul E. McKenney
2022-10-02 15:55     ` Frederic Weisbecker
2022-10-02 15:57       ` Frederic Weisbecker
2022-10-02 16:10         ` Paul E. McKenney
2022-10-02 16:09       ` Paul E. McKenney
2022-10-02 21:47         ` Frederic Weisbecker
2022-10-02 23:46           ` Paul E. McKenney
2022-10-03  9:55             ` Frederic Weisbecker
2022-10-03 11:52               ` Paul E. McKenney
2022-10-18 14:31     ` John Ogness
2022-10-18 15:18       ` Paul E. McKenney
2022-09-29 18:07   ` [PATCH RFC v2 rcu 3/8] srcu: Check for consistent per-CPU per-srcu_struct NMI safety Paul E. McKenney
2022-10-02 22:06     ` Frederic Weisbecker
2022-10-02 23:51       ` Paul E. McKenney
2022-10-03 10:13         ` Frederic Weisbecker
2022-10-03 11:57           ` Paul E. McKenney
2022-10-03 12:37             ` Frederic Weisbecker
2022-10-03 13:32               ` Paul E. McKenney
2022-10-03 13:36                 ` Frederic Weisbecker
2022-09-29 18:07   ` [PATCH RFC v2 rcu 4/8] srcu: Check for consistent global " Paul E. McKenney
2022-09-29 18:07   ` [PATCH RFC v2 rcu 5/8] arch/x86: Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option Paul E. McKenney
2022-09-29 18:07   ` [PATCH RFC v2 rcu 6/8] arch/arm64: " Paul E. McKenney
2022-09-29 18:07     ` Paul E. McKenney
2022-10-05 11:12     ` Mark Rutland
2022-10-05 11:12       ` Mark Rutland
2022-09-29 18:07   ` [PATCH RFC v2 rcu 7/8] arch/loongarch: " Paul E. McKenney
2022-09-29 18:07   ` [PATCH RFC v2 rcu 8/8] arch/s390: " Paul E. McKenney
2022-10-03 14:11   ` [PATCH v2 rcu 0/8] NMI-safe SRCU reader API Frederic Weisbecker
2022-10-03 16:38     ` Paul E. McKenney
2022-10-14 22:47   ` Joel Fernandes
2022-10-14 22:52     ` Joel Fernandes
2022-10-18 10:33   ` John Ogness
2022-10-18 15:24     ` Paul E. McKenney
2022-10-18 18:44       ` John Ogness
2022-10-18 18:59         ` Paul E. McKenney
2022-10-18 21:57           ` Paul E. McKenney
2022-10-19 11:13             ` John Ogness
2022-10-19 19:14               ` Paul E. McKenney
2022-10-19 21:38                 ` John Ogness
2022-10-19 22:05                 ` Frederic Weisbecker
2022-10-20 22:27                   ` Paul E. McKenney
2022-10-20 22:41                     ` Paul E. McKenney
2022-10-21 12:27                     ` John Ogness
2022-10-21 13:59                       ` Paul E. McKenney
2022-10-21 18:41                       ` Paul E. McKenney
2022-10-24  6:15                         ` John Ogness
2022-10-24 13:47                           ` Paul E. McKenney
2022-10-27  9:31                             ` John Ogness
2022-10-27 14:10                               ` Paul E. McKenney
2022-10-27 14:39                                 ` John Ogness
2022-10-27 16:01                                   ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221001165152.GO4196@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=john.ogness@linutronix.de \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.