* [PATCH 0/5] A few smaller RCU related patches from the RT tree @ 2020-12-15 14:16 Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 1/5] rcu: make RCU_BOOST default on CONFIG_PREEMPT_RT Sebastian Andrzej Siewior ` (5 more replies) 0 siblings, 6 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 14:16 UTC (permalink / raw) To: rcu Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner Hi, I know the timming of this regarding the merge window is bad. I meant to send them for days… Initially I planned to send only 5/5 of the series but then I stumbled upon the other RCU related patches and I don't see a reason I shouldn't post them. I still have one patch regarding rcutorture which I hold on to until the current issues are resolved (in case you are curious: Scott made sure BH can disabled properly in atomic context on RT (while keeping this limitation to RT only builds). The current softirq implementation does not allow to disable BH in atomic context). Sebastian ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/5] rcu: make RCU_BOOST default on CONFIG_PREEMPT_RT 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior @ 2020-12-15 14:16 ` Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 2/5] rcu: Use rcuc threads on PREEMPT_RT Sebastian Andrzej Siewior ` (4 subsequent siblings) 5 siblings, 0 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 14:16 UTC (permalink / raw) To: rcu Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner, Sebastian Andrzej Siewior With RCU callbacks deferred to the `rcuc' thread it is more likely that people run into OOM if the RCU reader or the thread is stalled for too long and RCU can't continue its work. On PREEMPT_RT this is more likely because the amount of RT tasks is higher and the general workload involves more RT tasks. Make RCU_BOOST default on PREEMPT_RT to ease the configuration. It can be still disabled if someone knows better. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- kernel/rcu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index cdc57b4f6d48a..aa8cc8c977e78 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -188,8 +188,8 @@ config RCU_FAST_NO_HZ config RCU_BOOST bool "Enable RCU priority boosting" - depends on RT_MUTEXES && PREEMPT_RCU && RCU_EXPERT - default n + depends on (RT_MUTEXES && PREEMPT_RCU && RCU_EXPERT) || PREEMPT_RT + default y if PREEMPT_RT help This option boosts the priority of preempted RCU readers that block the current preemptible RCU grace period for too long. -- 2.29.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/5] rcu: Use rcuc threads on PREEMPT_RT. 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 1/5] rcu: make RCU_BOOST default on CONFIG_PREEMPT_RT Sebastian Andrzej Siewior @ 2020-12-15 14:16 ` Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 3/5] rcu: enable rcu_normal_after_boot by default for RT Sebastian Andrzej Siewior ` (3 subsequent siblings) 5 siblings, 0 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 14:16 UTC (permalink / raw) To: rcu Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner, Sebastian Andrzej Siewior From: Scott Wood <swood@redhat.com> Using rcuc threads for processing callbacks over softirq has the advantage that the callbacks can be processed independently. On PREEMPT_RT the softirq can be preempted. Relying on softirq for callback processing would mean to complete the current stage of softirq for the sake of running callbacks. The softirq is processed on PREEMPT_RT in the context of the task that is raising a softirq. If it is raised in-IRQ context then the softirq processing is deferred to the `ksoftirqd' thread. Processing RCU callbacks in thread context was always the only option for PREEMPT_RT and there have been no complains. Disable softirq usage for RCU and disable its commandline parameter. Signed-off-by: Scott Wood <swood@redhat.com> [bigeasy: Reword commit message] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- kernel/rcu/tree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 80ceee55f379a..57eff3b82104c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -100,8 +100,10 @@ static struct rcu_state rcu_state = { static bool dump_tree; module_param(dump_tree, bool, 0444); /* By default, use RCU_SOFTIRQ instead of rcuc kthreads. */ -static bool use_softirq = true; +static bool use_softirq = !IS_ENABLED(CONFIG_PREEMPT_RT); +#ifndef CONFIG_PREEMPT_RT module_param(use_softirq, bool, 0444); +#endif /* Control rcu_node-tree auto-balancing at boot time. */ static bool rcu_fanout_exact; module_param(rcu_fanout_exact, bool, 0444); -- 2.29.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 3/5] rcu: enable rcu_normal_after_boot by default for RT 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 1/5] rcu: make RCU_BOOST default on CONFIG_PREEMPT_RT Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 2/5] rcu: Use rcuc threads on PREEMPT_RT Sebastian Andrzej Siewior @ 2020-12-15 14:16 ` Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 4/5] doc: Update RCU's requirements page about the PREEMPT_RT wiki Sebastian Andrzej Siewior ` (2 subsequent siblings) 5 siblings, 0 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 14:16 UTC (permalink / raw) To: rcu Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner, Julia Cartwright, Luiz Capitulino, Paul E . McKenney, Sebastian Andrzej Siewior From: Julia Cartwright <julia@ni.com> The forcing of an expedited grace period is an expensive and very RT-application unfriendly operation, as it forcibly preempts all running tasks on CPUs which are preventing the gp from expiring. By default, as a policy decision, disable the expediting of grace periods (after boot) on configurations which enable PREEMPT_RT. Suggested-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Paul E. McKenney <paulmck@linux.ibm.com> Signed-off-by: Julia Cartwright <julia@ni.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- kernel/rcu/update.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index 39334d2d2b379..b95ae86c40a7d 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -56,8 +56,10 @@ #ifndef CONFIG_TINY_RCU module_param(rcu_expedited, int, 0); module_param(rcu_normal, int, 0); -static int rcu_normal_after_boot; +static int rcu_normal_after_boot = IS_ENABLED(CONFIG_PREEMPT_RT); +#ifndef CONFIG_PREEMPT_RT module_param(rcu_normal_after_boot, int, 0); +#endif #endif /* #ifndef CONFIG_TINY_RCU */ #ifdef CONFIG_DEBUG_LOCK_ALLOC -- 2.29.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 4/5] doc: Update RCU's requirements page about the PREEMPT_RT wiki. 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior ` (2 preceding siblings ...) 2020-12-15 14:16 ` [PATCH 3/5] rcu: enable rcu_normal_after_boot by default for RT Sebastian Andrzej Siewior @ 2020-12-15 14:16 ` Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 5/5] doc: Use CONFIG_PREEMPTION Sebastian Andrzej Siewior 2020-12-15 18:01 ` [PATCH 0/5] A few smaller RCU related patches from the RT tree Paul E. McKenney 5 siblings, 0 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 14:16 UTC (permalink / raw) To: rcu Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner, Sebastian Andrzej Siewior The PREEMPT_RT wiki moved from kernel.org to the Linux Foundation wiki. The kernel.org wiki is read only. Update the URL of the active PREEMPT_RT wiki. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- Documentation/RCU/Design/Requirements/Requirements.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 95b68c107a8fa..e93cdc476e008 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2317,7 +2317,7 @@ decides to throw at it. The Linux kernel is used for real-time workloads, especially in conjunction with the `-rt -patchset <https://rt.wiki.kernel.org/index.php/Main_Page>`__. The +patchset <https://wiki.linuxfoundation.org/realtime/>`__. The real-time-latency response requirements are such that the traditional approach of disabling preemption across RCU read-side critical sections is inappropriate. Kernels built with ``CONFIG_PREEMPT=y`` therefore use -- 2.29.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 5/5] doc: Use CONFIG_PREEMPTION 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior ` (3 preceding siblings ...) 2020-12-15 14:16 ` [PATCH 4/5] doc: Update RCU's requirements page about the PREEMPT_RT wiki Sebastian Andrzej Siewior @ 2020-12-15 14:16 ` Sebastian Andrzej Siewior 2020-12-15 18:01 ` [PATCH 0/5] A few smaller RCU related patches from the RT tree Paul E. McKenney 5 siblings, 0 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 14:16 UTC (permalink / raw) To: rcu Cc: Paul E. McKenney, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner, Sebastian Andrzej Siewior CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Update the documents and mention CONFIG_PREEMPTION. Spell out CONFIG_PREEMPT_RT (instead PREEMPT_RT) since it is an option now. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- .../Expedited-Grace-Periods.rst | 4 ++-- .../RCU/Design/Requirements/Requirements.rst | 22 +++++++++---------- Documentation/RCU/checklist.rst | 2 +- Documentation/RCU/rcubarrier.rst | 6 ++--- Documentation/RCU/stallwarn.rst | 4 ++-- Documentation/RCU/whatisRCU.rst | 10 ++++----- 6 files changed, 24 insertions(+), 24 deletions(-) diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst index 72f0f6fbd53c0..6f89cf1e567d0 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst @@ -38,7 +38,7 @@ sections. RCU-preempt Expedited Grace Periods =================================== -``CONFIG_PREEMPT=y`` kernels implement RCU-preempt. +``CONFIG_PREEMPTION=y`` kernels implement RCU-preempt. The overall flow of the handling of a given CPU by an RCU-preempt expedited grace period is shown in the following diagram: @@ -112,7 +112,7 @@ things. RCU-sched Expedited Grace Periods --------------------------------- -``CONFIG_PREEMPT=n`` kernels implement RCU-sched. The overall flow of +``CONFIG_PREEMPTION=n`` kernels implement RCU-sched. The overall flow of the handling of a given CPU by an RCU-sched expedited grace period is shown in the following diagram: diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index e93cdc476e008..0da9133fa13ab 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -78,7 +78,7 @@ RCU treats a nested set as one big RCU read-side critical section. Production-quality implementations of rcu_read_lock() and rcu_read_unlock() are extremely lightweight, and in fact have exactly zero overhead in Linux kernels built for production use with -``CONFIG_PREEMPT=n``. +``CONFIG_PREEMPTION=n``. This guarantee allows ordering to be enforced with extremely low overhead to readers, for example: @@ -1181,7 +1181,7 @@ and has become decreasingly so as memory sizes have expanded and memory costs have plummeted. However, as I learned from Matt Mackall's `bloatwatch <http://elinux.org/Linux_Tiny-FAQ>`__ efforts, memory footprint is critically important on single-CPU systems with -non-preemptible (``CONFIG_PREEMPT=n``) kernels, and thus `tiny +non-preemptible (``CONFIG_PREEMPTION=n``) kernels, and thus `tiny RCU <https://lore.kernel.org/r/20090113221724.GA15307@linux.vnet.ibm.com>`__ was born. Josh Triplett has since taken over the small-memory banner with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__ @@ -1497,7 +1497,7 @@ limitations. Implementations of RCU for which rcu_read_lock() and rcu_read_unlock() generate no code, such as Linux-kernel RCU when -``CONFIG_PREEMPT=n``, can be nested arbitrarily deeply. After all, there +``CONFIG_PREEMPTION=n``, can be nested arbitrarily deeply. After all, there is no overhead. Except that if all these instances of rcu_read_lock() and rcu_read_unlock() are visible to the compiler, compilation will eventually fail due to exhausting memory, @@ -1769,7 +1769,7 @@ implementation can be a no-op. However, once the scheduler has spawned its first kthread, this early boot trick fails for synchronize_rcu() (as well as for -synchronize_rcu_expedited()) in ``CONFIG_PREEMPT=y`` kernels. The +synchronize_rcu_expedited()) in ``CONFIG_PREEMPTION=y`` kernels. The reason is that an RCU read-side critical section might be preempted, which means that a subsequent synchronize_rcu() really does have to wait for something, as opposed to simply returning immediately. @@ -2038,7 +2038,7 @@ The compiler must not be permitted to transform this source code into 5 rcu_read_unlock(); 6 do_something_with(v, user_v); -If the compiler did make this transformation in a ``CONFIG_PREEMPT=n`` kernel +If the compiler did make this transformation in a ``CONFIG_PREEMPTION=n`` kernel build, and if get_user() did page fault, the result would be a quiescent state in the middle of an RCU read-side critical section. This misplaced quiescent state could result in line 4 being a use-after-free access, @@ -2320,7 +2320,7 @@ conjunction with the `-rt patchset <https://wiki.linuxfoundation.org/realtime/>`__. The real-time-latency response requirements are such that the traditional approach of disabling preemption across RCU read-side critical sections -is inappropriate. Kernels built with ``CONFIG_PREEMPT=y`` therefore use +is inappropriate. Kernels built with ``CONFIG_PREEMPTION=y`` therefore use an RCU implementation that allows RCU read-side critical sections to be preempted. This requirement made its presence known after users made it clear that an earlier `real-time @@ -2460,11 +2460,11 @@ not have this property, given that any point in the code outside of an RCU read-side critical section can be a quiescent state. Therefore, *RCU-sched* was created, which follows “classic” RCU in that an RCU-sched grace period waits for pre-existing interrupt and NMI -handlers. In kernels built with ``CONFIG_PREEMPT=n``, the RCU and +handlers. In kernels built with ``CONFIG_PREEMPTION=n``, the RCU and RCU-sched APIs have identical implementations, while kernels built with -``CONFIG_PREEMPT=y`` provide a separate implementation for each. +``CONFIG_PREEMPTION=y`` provide a separate implementation for each. -Note well that in ``CONFIG_PREEMPT=y`` kernels, +Note well that in ``CONFIG_PREEMPTION=y`` kernels, rcu_read_lock_sched() and rcu_read_unlock_sched() disable and re-enable preemption, respectively. This means that if there was a preemption attempt during the RCU-sched read-side critical section, @@ -2645,10 +2645,10 @@ userspace execution also delimit tasks-RCU read-side critical sections. The tasks-RCU API is quite compact, consisting only of call_rcu_tasks(), synchronize_rcu_tasks(), and -rcu_barrier_tasks(). In ``CONFIG_PREEMPT=n`` kernels, trampolines +rcu_barrier_tasks(). In ``CONFIG_PREEMPTION=n`` kernels, trampolines cannot be preempted, so these APIs map to call_rcu(), synchronize_rcu(), and rcu_barrier(), respectively. In -``CONFIG_PREEMPT=y`` kernels, trampolines can be preempted, and these +``CONFIG_PREEMPTION=y`` kernels, trampolines can be preempted, and these three APIs are therefore implemented by separate functions that check for voluntary context switches. diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 2d1dc1deffc9a..1030119294d08 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -212,7 +212,7 @@ over a rather long period of time, but improvements are always welcome! the rest of the system. 7. As of v4.20, a given kernel implements only one RCU flavor, - which is RCU-sched for PREEMPT=n and RCU-preempt for PREEMPT=y. + which is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. If the updater uses call_rcu() or synchronize_rcu(), then the corresponding readers may use rcu_read_lock() and rcu_read_unlock(), rcu_read_lock_bh() and rcu_read_unlock_bh(), diff --git a/Documentation/RCU/rcubarrier.rst b/Documentation/RCU/rcubarrier.rst index f64f4413a47c4..3b4a248774961 100644 --- a/Documentation/RCU/rcubarrier.rst +++ b/Documentation/RCU/rcubarrier.rst @@ -9,7 +9,7 @@ RCU (read-copy update) is a synchronization mechanism that can be thought of as a replacement for read-writer locking (among other things), but with very low-overhead readers that are immune to deadlock, priority inversion, and unbounded latency. RCU read-side critical sections are delimited -by rcu_read_lock() and rcu_read_unlock(), which, in non-CONFIG_PREEMPT +by rcu_read_lock() and rcu_read_unlock(), which, in non-CONFIG_PREEMPTION kernels, generate no code whatsoever. This means that RCU writers are unaware of the presence of concurrent @@ -329,10 +329,10 @@ Answer: This cannot happen. The reason is that on_each_cpu() has its last to smp_call_function() and further to smp_call_function_on_cpu(), causing this latter to spin until the cross-CPU invocation of rcu_barrier_func() has completed. This by itself would prevent - a grace period from completing on non-CONFIG_PREEMPT kernels, + a grace period from completing on non-CONFIG_PREEMPTION kernels, since each CPU must undergo a context switch (or other quiescent state) before the grace period can complete. However, this is - of no use in CONFIG_PREEMPT kernels. + of no use in CONFIG_PREEMPTION kernels. Therefore, on_each_cpu() disables preemption across its call to smp_call_function() and also across the local call to diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index d53856cc63908..7148e9be08c34 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -25,7 +25,7 @@ So your kernel printed an RCU CPU stall warning. The next question is - A CPU looping with bottom halves disabled. -- For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel +- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the kernel without invoking schedule(). If the looping in the kernel is really expected and desirable behavior, you might need to add some calls to cond_resched(). @@ -44,7 +44,7 @@ So your kernel printed an RCU CPU stall warning. The next question is result in the ``rcu_.*kthread starved for`` console-log message, which will include additional debugging information. -- A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might +- A CPU-bound real-time task in a CONFIG_PREEMPTION kernel, which might happen to preempt a low-priority task in the middle of an RCU read-side critical section. This is especially damaging if that low-priority task is not permitted to run on any other CPU, diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 1a4723f48bd9c..17e95ab2a2014 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -683,7 +683,7 @@ so there can be no deadlock cycle. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section presents a "toy" RCU implementation that is based on "classic RCU". It is also short on performance (but only for updates) and -on features such as hotplug CPU and the ability to run in CONFIG_PREEMPT +on features such as hotplug CPU and the ability to run in CONFIG_PREEMPTION kernels. The definitions of rcu_dereference() and rcu_assign_pointer() are the same as those shown in the preceding section, so they are omitted. :: @@ -739,7 +739,7 @@ to that data item, so we can safely reclaim it. Quick Quiz #3: If it is illegal to block in an RCU read-side critical section, what the heck do you do in - PREEMPT_RT, where normal spinlocks can block??? + CONFIG_PREEMPT_RT, where normal spinlocks can block??? :ref:`Answers to Quick Quiz <8_whatisRCU>` @@ -1093,7 +1093,7 @@ the right tool for your job. overhead is **negative**. Answer: - Imagine a single-CPU system with a non-CONFIG_PREEMPT + Imagine a single-CPU system with a non-CONFIG_PREEMPTION kernel where a routing table is used by process-context code, but can be updated by irq-context code (for example, by an "ICMP REDIRECT" packet). The usual way of handling @@ -1120,10 +1120,10 @@ the right tool for your job. Quick Quiz #3: If it is illegal to block in an RCU read-side critical section, what the heck do you do in - PREEMPT_RT, where normal spinlocks can block??? + CONFIG_PREEMPT_RT, where normal spinlocks can block??? Answer: - Just as PREEMPT_RT permits preemption of spinlock + Just as CONFIG_PREEMPT_RT permits preemption of spinlock critical sections, it permits preemption of RCU read-side critical sections. It also permits spinlocks blocking while in RCU read-side critical -- 2.29.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 0/5] A few smaller RCU related patches from the RT tree 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior ` (4 preceding siblings ...) 2020-12-15 14:16 ` [PATCH 5/5] doc: Use CONFIG_PREEMPTION Sebastian Andrzej Siewior @ 2020-12-15 18:01 ` Paul E. McKenney 2020-12-15 20:47 ` Sebastian Andrzej Siewior 5 siblings, 1 reply; 8+ messages in thread From: Paul E. McKenney @ 2020-12-15 18:01 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: rcu, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner On Tue, Dec 15, 2020 at 03:16:44PM +0100, Sebastian Andrzej Siewior wrote: > Hi, > > I know the timming of this regarding the merge window is bad. I meant to > send them for days… Not a problem! However, unless any of these are urgent, I plan to submit them not into this merge window, but rather into the v5.12 merge window. (I don't see any of them being urgent, but I could well be missing something.) > Initially I planned to send only 5/5 of the series but then I stumbled > upon the other RCU related patches and I don't see a reason I shouldn't > post them. > I still have one patch regarding rcutorture which I hold on to until the > current issues are resolved (in case you are curious: Scott made sure BH > can disabled properly in atomic context on RT (while keeping this > limitation to RT only builds). The current softirq implementation does > not allow to disable BH in atomic context). Queued and pushed, thank you all! Nice automation of PREEMPT_RT configuration. I have done my usual wordsmithing, so if any of you see anything I messed up, please don't keep it a secret. I also updated #2 and #3 to change kernel-parameters.txt accordingly. Thanx, Paul ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/5] A few smaller RCU related patches from the RT tree 2020-12-15 18:01 ` [PATCH 0/5] A few smaller RCU related patches from the RT tree Paul E. McKenney @ 2020-12-15 20:47 ` Sebastian Andrzej Siewior 0 siblings, 0 replies; 8+ messages in thread From: Sebastian Andrzej Siewior @ 2020-12-15 20:47 UTC (permalink / raw) To: Paul E. McKenney Cc: rcu, Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Joel Fernandes, Scott Wood, Thomas Gleixner On 2020-12-15 10:01:06 [-0800], Paul E. McKenney wrote: > On Tue, Dec 15, 2020 at 03:16:44PM +0100, Sebastian Andrzej Siewior wrote: > > Hi, > > > > I know the timming of this regarding the merge window is bad. I meant to > > send them for days… > > Not a problem! > > However, unless any of these are urgent, I plan to submit them not into > this merge window, but rather into the v5.12 merge window. (I don't > see any of them being urgent, but I could well be missing something.) perfect, thank you. > I have done my usual wordsmithing, so if any of you see anything I messed > up, please don't keep it a secret. I'm going to backport them into my RT queue tomorrow and I promise not keep a secret :) > I also updated #2 and #3 to change kernel-parameters.txt accordingly. Thank you. > Thanx, Paul Sebastian ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-12-15 20:48 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-15 14:16 [PATCH 0/5] A few smaller RCU related patches from the RT tree Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 1/5] rcu: make RCU_BOOST default on CONFIG_PREEMPT_RT Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 2/5] rcu: Use rcuc threads on PREEMPT_RT Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 3/5] rcu: enable rcu_normal_after_boot by default for RT Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 4/5] doc: Update RCU's requirements page about the PREEMPT_RT wiki Sebastian Andrzej Siewior 2020-12-15 14:16 ` [PATCH 5/5] doc: Use CONFIG_PREEMPTION Sebastian Andrzej Siewior 2020-12-15 18:01 ` [PATCH 0/5] A few smaller RCU related patches from the RT tree Paul E. McKenney 2020-12-15 20:47 ` Sebastian Andrzej Siewior
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).