* [PATCH] rcu: Direct boosting gp_tasks for strict grace periods @ 2022-05-13 0:42 Zqiang 2022-05-13 1:06 ` Paul E. McKenney 0 siblings, 1 reply; 6+ messages in thread From: Zqiang @ 2022-05-13 0:42 UTC (permalink / raw) To: paulmck, frederic; +Cc: rcu, linux-kernel If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal grace period will be treated as expedited grace period, the gp_tasks that block current grace period needs to be boosted unconditionally, therefore this commit adds Kconfig check in rcu_initiate_boost(). Signed-off-by: Zqiang <qiang1.zhang@intel.com> --- kernel/rcu/tree_plugin.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 99cde4c94769..a60f2edf8e59 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags) (rnp->gp_tasks != NULL && rnp->boost_tasks == NULL && rnp->qsmask == 0 && - (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) { + (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld || + IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) { if (rnp->exp_tasks == NULL) WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); -- 2.25.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] rcu: Direct boosting gp_tasks for strict grace periods 2022-05-13 0:42 [PATCH] rcu: Direct boosting gp_tasks for strict grace periods Zqiang @ 2022-05-13 1:06 ` Paul E. McKenney 2022-05-13 13:17 ` Zhang, Qiang1 0 siblings, 1 reply; 6+ messages in thread From: Paul E. McKenney @ 2022-05-13 1:06 UTC (permalink / raw) To: Zqiang; +Cc: frederic, rcu, linux-kernel On Fri, May 13, 2022 at 08:42:55AM +0800, Zqiang wrote: > If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal grace > period will be treated as expedited grace period, the gp_tasks that block > current grace period needs to be boosted unconditionally, therefore this > commit adds Kconfig check in rcu_initiate_boost(). > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> Good eyes! I have queued this for further review and testing, thank you! What sorts of tests did you run on it? As usual, I could not resist the urge to wordsmith, so could you please check the version shown below? Thanx, Paul ------------------------------------------------------------------------ commit 079e0f894c5d887c678f94332c1fa7287abfd6bc Author: Zqiang <qiang1.zhang@intel.com> Date: Fri May 13 08:42:55 2022 +0800 rcu: Immediately boost preempted readers for strict grace periods The intent of the CONFIG_RCU_STRICT_GRACE_PERIOD Konfig option is to cause normal grace periods to complete quickly in order to better catch errors resulting from improperly leaking pointers from RCU read-side critical sections. However, kernels built with this option enabled still wait for some hundreds of milliseconds before boosting RCU readers that have been preempted within their current critical section. The value of this delay is set by the CONFIG_RCU_BOOST_DELAY Kconfig option, which defaults to 500 milliseconds. This commit therefore causes kernels build with strict grace periods to ignore CONFIG_RCU_BOOST_DELAY. This causes rcu_initiate_boost() to start boosting immediately after all CPUs on a given leaf rcu_node structure have passed through their quiescent states. Signed-off-by: Zqiang <qiang1.zhang@intel.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 99cde4c947699..b4ab952f04ea6 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags) (rnp->gp_tasks != NULL && rnp->boost_tasks == NULL && rnp->qsmask == 0 && - (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) { + (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld || + IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) { if (rnp->exp_tasks == NULL) WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); ^ permalink raw reply related [flat|nested] 6+ messages in thread
* RE: [PATCH] rcu: Direct boosting gp_tasks for strict grace periods 2022-05-13 1:06 ` Paul E. McKenney @ 2022-05-13 13:17 ` Zhang, Qiang1 2022-05-13 14:14 ` Paul E. McKenney 0 siblings, 1 reply; 6+ messages in thread From: Zhang, Qiang1 @ 2022-05-13 13:17 UTC (permalink / raw) To: paulmck; +Cc: frederic, rcu, linux-kernel On Fri, May 13, 2022 at 08:42:55AM +0800, Zqiang wrote: > If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal > grace period will be treated as expedited grace period, the gp_tasks > that block current grace period needs to be boosted unconditionally, > therefore this commit adds Kconfig check in rcu_initiate_boost(). > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> >Good eyes! I have queued this for further review and testing, thank you! > >What sorts of tests did you run on it? Hi Paul I didn't think of suitable test method, Can you provide me with a test method to test it, I will be happy to test. Thanks, Zqiang > >As usual, I could not resist the urge to wordsmith, so could you please check the version shown below? > > Thanx, Paul ------------------------------------------------------------------------ commit 079e0f894c5d887c678f94332c1fa7287abfd6bc Author: Zqiang <qiang1.zhang@intel.com> Date: Fri May 13 08:42:55 2022 +0800 rcu: Immediately boost preempted readers for strict grace periods The intent of the CONFIG_RCU_STRICT_GRACE_PERIOD Konfig option is to cause normal grace periods to complete quickly in order to better catch errors resulting from improperly leaking pointers from RCU read-side critical sections. However, kernels built with this option enabled still wait for some hundreds of milliseconds before boosting RCU readers that have been preempted within their current critical section. The value of this delay is set by the CONFIG_RCU_BOOST_DELAY Kconfig option, which defaults to 500 milliseconds. This commit therefore causes kernels build with strict grace periods to ignore CONFIG_RCU_BOOST_DELAY. This causes rcu_initiate_boost() to start boosting immediately after all CPUs on a given leaf rcu_node structure have passed through their quiescent states. Signed-off-by: Zqiang <qiang1.zhang@intel.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 99cde4c947699..b4ab952f04ea6 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags) (rnp->gp_tasks != NULL && rnp->boost_tasks == NULL && rnp->qsmask == 0 && - (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) { + (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld || + IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) { if (rnp->exp_tasks == NULL) WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] rcu: Direct boosting gp_tasks for strict grace periods 2022-05-13 13:17 ` Zhang, Qiang1 @ 2022-05-13 14:14 ` Paul E. McKenney 2022-05-17 12:32 ` Zhang, Qiang1 0 siblings, 1 reply; 6+ messages in thread From: Paul E. McKenney @ 2022-05-13 14:14 UTC (permalink / raw) To: Zhang, Qiang1; +Cc: frederic, rcu, linux-kernel On Fri, May 13, 2022 at 01:17:16PM +0000, Zhang, Qiang1 wrote: > > On Fri, May 13, 2022 at 08:42:55AM +0800, Zqiang wrote: > > If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal > > grace period will be treated as expedited grace period, the gp_tasks > > that block current grace period needs to be boosted unconditionally, > > therefore this commit adds Kconfig check in rcu_initiate_boost(). > > > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > > >Good eyes! I have queued this for further review and testing, thank you! > > > >What sorts of tests did you run on it? > > Hi Paul > > I didn't think of suitable test method, > Can you provide me with a test method to test it, I will be happy to test. Here is one possibility: tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 60 --configs "TREE01 TREE02 TREE03 TREE04 TREE05 TREE07 TREE09 TREE10" --kconfig "CONFIG_NR_CPUS=4 CONFIG_RCU_STRICT_GRACE_PERIOD=y" --trust-make On a 16-CPU system, this will do eight kernel builds and run about two hours of testing. Thanx, Paul > Thanks, > Zqiang > > > > >As usual, I could not resist the urge to wordsmith, so could you please check the version shown below? > > > > Thanx, Paul > > ------------------------------------------------------------------------ > > commit 079e0f894c5d887c678f94332c1fa7287abfd6bc > Author: Zqiang <qiang1.zhang@intel.com> > Date: Fri May 13 08:42:55 2022 +0800 > > rcu: Immediately boost preempted readers for strict grace periods > > The intent of the CONFIG_RCU_STRICT_GRACE_PERIOD Konfig option is to > cause normal grace periods to complete quickly in order to better catch > errors resulting from improperly leaking pointers from RCU read-side > critical sections. However, kernels built with this option enabled still > wait for some hundreds of milliseconds before boosting RCU readers that > have been preempted within their current critical section. The value > of this delay is set by the CONFIG_RCU_BOOST_DELAY Kconfig option, > which defaults to 500 milliseconds. > > This commit therefore causes kernels build with strict grace periods > to ignore CONFIG_RCU_BOOST_DELAY. This causes rcu_initiate_boost() > to start boosting immediately after all CPUs on a given leaf rcu_node > structure have passed through their quiescent states. > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 99cde4c947699..b4ab952f04ea6 100644 > --- a/kernel/rcu/tree_plugin.h > +++ b/kernel/rcu/tree_plugin.h > @@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags) > (rnp->gp_tasks != NULL && > rnp->boost_tasks == NULL && > rnp->qsmask == 0 && > - (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) { > + (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld || > + IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) { > if (rnp->exp_tasks == NULL) > WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks); > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] rcu: Direct boosting gp_tasks for strict grace periods 2022-05-13 14:14 ` Paul E. McKenney @ 2022-05-17 12:32 ` Zhang, Qiang1 2022-05-18 1:03 ` Paul E. McKenney 0 siblings, 1 reply; 6+ messages in thread From: Zhang, Qiang1 @ 2022-05-17 12:32 UTC (permalink / raw) To: paulmck; +Cc: frederic, rcu, linux-kernel On Fri, May 13, 2022 at 01:17:16PM +0000, Zhang, Qiang1 wrote: > > On Fri, May 13, 2022 at 08:42:55AM +0800, Zqiang wrote: > > If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal > > grace period will be treated as expedited grace period, the gp_tasks > > that block current grace period needs to be boosted unconditionally, > > therefore this commit adds Kconfig check in rcu_initiate_boost(). > > > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > > >Good eyes! I have queued this for further review and testing, thank you! > > > >What sorts of tests did you run on it? > > Hi Paul > > I didn't think of suitable test method, Can you provide me with a > test method to test it, I will be happy to test. > >Here is one possibility: > >tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 60 --configs "TREE01 TREE02 TREE03 TREE04 TREE05 TREE07 TREE09 TREE10" --kconfig "CONFIG_NR_CPUS=4 CONFIG_RCU_STRICT_GRACE_PERIOD=y" --trust-make > >On a 16-CPU system, this will do eight kernel builds and run about two hours of testing. Hi Paul I tested according to the above command, and the results are as follows: tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 60 --configs TREE01 TREE02 TREE03 TREE04 TREE05 TREE07 TREE09 TREE10 --kconfig CONFIG_NR_CPUS=4 CONFIG_RCU_STRICT_GRACE_PERIOD=y --trust-make TREE01 ------- 154236 GPs (42.8433/s) [rcu: g1986553 f0x0 total-gps=496930] :CONFIG_NR_CPUS=4: improperly set :CONFIG_RCU_STRICT_GRACE_PERIOD=y: improperly set TREE02 ------- 410546 GPs (114.041/s) [rcu: g196373325 f0x2 total-gps=49093612] n_max_cbs: 805081 TREE03 ------- 160648 GPs (44.6244/s) [rcu: g128673793 f0x0 total-gps=32168735] n_max_cbs: 646284 TREE04 ------- 347059 GPs (96.4053/s) [rcu: g539425233 f0x2 total-gps=134856594] n_max_cbs: 205907 TREE05 ------- 360973 GPs (100.27/s) [rcu: g77594645 f0x0 total-gps=19398951] n_max_cbs: 31033 :CONFIG_RCU_FANOUT_LEAF=6: improperly set TREE07 ------- 355903 GPs (98.8619/s) [rcu: g639182469 f0x0 total-gps=159795908] n_max_cbs: 259737 TREE09 ------- 305700 GPs (84.9167/s) [rcu: g9668841 f0x0 total-gps=2417506] n_max_cbs: 2498623 :CONFIG_NR_CPUS=4: improperly set :CONFIG_RCU_STRICT_GRACE_PERIOD=y: improperly set TREE10 ------- 220566 GPs (61.2683/s) [rcu: g3456465 f0x0 total-gps=864409] n_max_cbs: 507348 :CONFIG_RCU_STRICT_GRACE_PERIOD=y: improperly set Thanks Zqiang > > Thanx, Paul > Thanks, > Zqiang > > > > >As usual, I could not resist the urge to wordsmith, so could you please check the version shown below? > > > > Thanx, Paul > > ---------------------------------------------------------------------- > -- > > commit 079e0f894c5d887c678f94332c1fa7287abfd6bc > Author: Zqiang <qiang1.zhang@intel.com> > Date: Fri May 13 08:42:55 2022 +0800 > > rcu: Immediately boost preempted readers for strict grace periods > > The intent of the CONFIG_RCU_STRICT_GRACE_PERIOD Konfig option is to > cause normal grace periods to complete quickly in order to better catch > errors resulting from improperly leaking pointers from RCU read-side > critical sections. However, kernels built with this option enabled still > wait for some hundreds of milliseconds before boosting RCU readers that > have been preempted within their current critical section. The value > of this delay is set by the CONFIG_RCU_BOOST_DELAY Kconfig option, > which defaults to 500 milliseconds. > > This commit therefore causes kernels build with strict grace periods > to ignore CONFIG_RCU_BOOST_DELAY. This causes rcu_initiate_boost() > to start boosting immediately after all CPUs on a given leaf rcu_node > structure have passed through their quiescent states. > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index > 99cde4c947699..b4ab952f04ea6 100644 > --- a/kernel/rcu/tree_plugin.h > +++ b/kernel/rcu/tree_plugin.h > @@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags) > (rnp->gp_tasks != NULL && > rnp->boost_tasks == NULL && > rnp->qsmask == 0 && > - (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) { > + (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld || > + IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) { > if (rnp->exp_tasks == NULL) > WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks); > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] rcu: Direct boosting gp_tasks for strict grace periods 2022-05-17 12:32 ` Zhang, Qiang1 @ 2022-05-18 1:03 ` Paul E. McKenney 0 siblings, 0 replies; 6+ messages in thread From: Paul E. McKenney @ 2022-05-18 1:03 UTC (permalink / raw) To: Zhang, Qiang1; +Cc: frederic, rcu, linux-kernel On Tue, May 17, 2022 at 12:32:10PM +0000, Zhang, Qiang1 wrote: > On Fri, May 13, 2022 at 01:17:16PM +0000, Zhang, Qiang1 wrote: > > > > On Fri, May 13, 2022 at 08:42:55AM +0800, Zqiang wrote: > > > If the CONFIG_RCU_STRICT_GRACE_PERIOD option is enabled, the normal > > > grace period will be treated as expedited grace period, the gp_tasks > > > that block current grace period needs to be boosted unconditionally, > > > therefore this commit adds Kconfig check in rcu_initiate_boost(). > > > > > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > > > > >Good eyes! I have queued this for further review and testing, thank you! > > > > > >What sorts of tests did you run on it? > > > > Hi Paul > > > > I didn't think of suitable test method, Can you provide me with a > > test method to test it, I will be happy to test. > > > >Here is one possibility: > > > >tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 60 --configs "TREE01 TREE02 TREE03 TREE04 TREE05 TREE07 TREE09 TREE10" --kconfig "CONFIG_NR_CPUS=4 CONFIG_RCU_STRICT_GRACE_PERIOD=y" --trust-make > > > >On a 16-CPU system, this will do eight kernel builds and run about two hours of testing. > > Hi Paul > > I tested according to the above command, and the results are as follows: > > tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 60 --configs TREE01 TREE02 TREE03 TREE04 TREE05 TREE07 TREE09 TREE10 --kconfig CONFIG_NR_CPUS=4 CONFIG_RCU_STRICT_GRACE_PERIOD=y --trust-make > TREE01 ------- 154236 GPs (42.8433/s) [rcu: g1986553 f0x0 total-gps=496930] > :CONFIG_NR_CPUS=4: improperly set > :CONFIG_RCU_STRICT_GRACE_PERIOD=y: improperly set This one didn't cooperate because other Kconfig setting force a minimum CONFIG_NR_CPUS of 8192, so OK. > TREE02 ------- 410546 GPs (114.041/s) [rcu: g196373325 f0x2 total-gps=49093612] n_max_cbs: 805081 > TREE03 ------- 160648 GPs (44.6244/s) [rcu: g128673793 f0x0 total-gps=32168735] n_max_cbs: 646284 > TREE04 ------- 347059 GPs (96.4053/s) [rcu: g539425233 f0x2 total-gps=134856594] n_max_cbs: 205907 > TREE05 ------- 360973 GPs (100.27/s) [rcu: g77594645 f0x0 total-gps=19398951] n_max_cbs: 31033 > :CONFIG_RCU_FANOUT_LEAF=6: improperly set This is harmless -- CONFIG_RCU_STRICT_GRACE_PERIOD sets an upper limit of 3 for CONFIG_RCU_FANOUT_LEAF. > TREE07 ------- 355903 GPs (98.8619/s) [rcu: g639182469 f0x0 total-gps=159795908] n_max_cbs: 259737 > TREE09 ------- 305700 GPs (84.9167/s) [rcu: g9668841 f0x0 total-gps=2417506] n_max_cbs: 2498623 > :CONFIG_NR_CPUS=4: improperly set > :CONFIG_RCU_STRICT_GRACE_PERIOD=y: improperly set This one is because TREE09 does not define CONFIG_RCU_EXPERT, on which CONFIG_RCU_STRICT_GRACE_PERIOD depends. > TREE10 ------- 220566 GPs (61.2683/s) [rcu: g3456465 f0x0 total-gps=864409] n_max_cbs: 507348 > :CONFIG_RCU_STRICT_GRACE_PERIOD=y: improperly set This one is because TREE10 also does not define CONFIG_RCU_EXPERT, on which CONFIG_RCU_STRICT_GRACE_PERIOD depends. So very good, and thank you! Thanx, Paul > Thanks > Zqiang > > > > > Thanx, Paul > > > Thanks, > > Zqiang > > > > > > > >As usual, I could not resist the urge to wordsmith, so could you please check the version shown below? > > > > > > Thanx, Paul > > > > ---------------------------------------------------------------------- > > -- > > > > commit 079e0f894c5d887c678f94332c1fa7287abfd6bc > > Author: Zqiang <qiang1.zhang@intel.com> > > Date: Fri May 13 08:42:55 2022 +0800 > > > > rcu: Immediately boost preempted readers for strict grace periods > > > > The intent of the CONFIG_RCU_STRICT_GRACE_PERIOD Konfig option is to > > cause normal grace periods to complete quickly in order to better catch > > errors resulting from improperly leaking pointers from RCU read-side > > critical sections. However, kernels built with this option enabled still > > wait for some hundreds of milliseconds before boosting RCU readers that > > have been preempted within their current critical section. The value > > of this delay is set by the CONFIG_RCU_BOOST_DELAY Kconfig option, > > which defaults to 500 milliseconds. > > > > This commit therefore causes kernels build with strict grace periods > > to ignore CONFIG_RCU_BOOST_DELAY. This causes rcu_initiate_boost() > > to start boosting immediately after all CPUs on a given leaf rcu_node > > structure have passed through their quiescent states. > > > > Signed-off-by: Zqiang <qiang1.zhang@intel.com> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index > > 99cde4c947699..b4ab952f04ea6 100644 > > --- a/kernel/rcu/tree_plugin.h > > +++ b/kernel/rcu/tree_plugin.h > > @@ -1159,7 +1159,8 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags) > > (rnp->gp_tasks != NULL && > > rnp->boost_tasks == NULL && > > rnp->qsmask == 0 && > > - (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld))) { > > + (!time_after(rnp->boost_time, jiffies) || rcu_state.cbovld || > > + IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD)))) { > > if (rnp->exp_tasks == NULL) > > WRITE_ONCE(rnp->boost_tasks, rnp->gp_tasks); > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-05-18 1:03 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-13 0:42 [PATCH] rcu: Direct boosting gp_tasks for strict grace periods Zqiang 2022-05-13 1:06 ` Paul E. McKenney 2022-05-13 13:17 ` Zhang, Qiang1 2022-05-13 14:14 ` Paul E. McKenney 2022-05-17 12:32 ` Zhang, Qiang1 2022-05-18 1:03 ` Paul E. McKenney
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.