PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC
which allows for dynamic switching of preemption models.
The choice of preemptible RCU or not, however, is fixed at compile
time. Given the trade-offs made to have a preemptible RCU, some
configurations which have limited preemption might prefer the
stronger forward-progress guarantees of PREEMPT_RCU=n.
Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC,
PREEMPT, PREEMPT_RT.
This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects
PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y,
PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y.
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
kernel/rcu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
index 3e079de0f5b4..1bfe7016724f 100644
--- a/kernel/rcu/Kconfig
+++ b/kernel/rcu/Kconfig
@@ -18,7 +18,7 @@ config TREE_RCU
config PREEMPT_RCU
bool
- default y if PREEMPTION
+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
select TREE_RCU
help
This option selects the RCU implementation that is
--
2.43.5On Wed, Oct 09, 2024 at 09:54:06AM -0700, Ankur Arora wrote: > PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC > which allows for dynamic switching of preemption models. > > The choice of preemptible RCU or not, however, is fixed at compile > time. Given the trade-offs made to have a preemptible RCU, some > configurations which have limited preemption might prefer the > stronger forward-progress guarantees of PREEMPT_RCU=n. > > Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC, > PREEMPT, PREEMPT_RT. > > This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects > PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y, > PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y. I am completely confused by this. Why do we want this? > Cc: Paul E. McKenney <paulmck@kernel.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> > --- > kernel/rcu/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > index 3e079de0f5b4..1bfe7016724f 100644 > --- a/kernel/rcu/Kconfig > +++ b/kernel/rcu/Kconfig > @@ -18,7 +18,7 @@ config TREE_RCU > > config PREEMPT_RCU > bool > - default y if PREEMPTION > + default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > select TREE_RCU > help > This option selects the RCU implementation that is > -- > 2.43.5 >
On Wed, Oct 09, 2024 at 08:01:17PM +0200, Peter Zijlstra wrote: > On Wed, Oct 09, 2024 at 09:54:06AM -0700, Ankur Arora wrote: > > PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC > > which allows for dynamic switching of preemption models. > > > > The choice of preemptible RCU or not, however, is fixed at compile > > time. Given the trade-offs made to have a preemptible RCU, some > > configurations which have limited preemption might prefer the > > stronger forward-progress guarantees of PREEMPT_RCU=n. > > > > Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC, > > PREEMPT, PREEMPT_RT. > > > > This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects > > PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y, > > PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y. > > I am completely confused by this. Why do we want this? In order to support systems that currently run CONFIG_PREEMPT=n that are adequately but not overly endowed with memory. If we allow all RCU readers to be preempted, we increase grace-period latency, and also increase OOM incidence. Which we would like to avoid. But we do want lazy preemption otherwise, for but one thing to reduce tail latencies and to reduce the need for preemption points. Thus, we want a way to allow lazy preemption in general, but to continue with non-preemptible RCU read-side critical sections. Or am I once again missing your point? Thanx, Paul > > Cc: Paul E. McKenney <paulmck@kernel.org> > > Cc: Peter Zijlstra <peterz@infradead.org> > > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> > > --- > > kernel/rcu/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > > index 3e079de0f5b4..1bfe7016724f 100644 > > --- a/kernel/rcu/Kconfig > > +++ b/kernel/rcu/Kconfig > > @@ -18,7 +18,7 @@ config TREE_RCU > > > > config PREEMPT_RCU > > bool > > - default y if PREEMPTION > > + default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > select TREE_RCU > > help > > This option selects the RCU implementation that is > > -- > > 2.43.5 > >
On 2024-10-09 11:24:09 [-0700], Paul E. McKenney wrote: > In order to support systems that currently run CONFIG_PREEMPT=n that … > Or am I once again missing your point? The change is: | config PREEMPT_RCU | bool |- default y if PREEMPTION |+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) Now: - CONFIG_PREEMPT select PREEMPT_BUILD - PREEMPT_RT select CONFIG_PREEMPTION - PREEMPT_DYNAMIC selects PREEMPT_BUILD and PREEMPT_BUILD select CONFIG_PREEMPTION so in the end, this change is a nop, right? > Thanx, Paul Sebastian
On Thu, Oct 10, 2024 at 08:32:07AM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-09 11:24:09 [-0700], Paul E. McKenney wrote: > > In order to support systems that currently run CONFIG_PREEMPT=n that > … > > Or am I once again missing your point? > > The change is: > | config PREEMPT_RCU > | bool > |- default y if PREEMPTION > |+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > Now: > - CONFIG_PREEMPT select PREEMPT_BUILD > - PREEMPT_RT select CONFIG_PREEMPTION > - PREEMPT_DYNAMIC selects PREEMPT_BUILD > > and PREEMPT_BUILD select CONFIG_PREEMPTION > > so in the end, this change is a nop, right? PREEMPT_RT selects PREEMPTION *and* has one of PREEMPT / PREEMPT_LAZY / PREEMPT_DYNAMIC, all of which in turn select PREEMPT_BUILD, which selects PREEMPTION. (arguably we can remove the select PREEMPTION from PREEMPT_RT) The proposed change is not a nop because the config: PREEMPT_LAZY=y PREEMPT_DYNAMIC=n will result in false, while it will have PREEMPTION. That said, I really do not agree with the change, it makes the condition complicated for no reason.
Peter Zijlstra <peterz@infradead.org> writes: > On Thu, Oct 10, 2024 at 08:32:07AM +0200, Sebastian Andrzej Siewior wrote: >> On 2024-10-09 11:24:09 [-0700], Paul E. McKenney wrote: >> > In order to support systems that currently run CONFIG_PREEMPT=n that >> … >> > Or am I once again missing your point? >> >> The change is: >> | config PREEMPT_RCU >> | bool >> |- default y if PREEMPTION >> |+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) >> >> Now: >> - CONFIG_PREEMPT select PREEMPT_BUILD >> - PREEMPT_RT select CONFIG_PREEMPTION >> - PREEMPT_DYNAMIC selects PREEMPT_BUILD >> >> and PREEMPT_BUILD select CONFIG_PREEMPTION >> >> so in the end, this change is a nop, right? > > PREEMPT_RT selects PREEMPTION *and* has one of PREEMPT / PREEMPT_LAZY / > PREEMPT_DYNAMIC, all of which in turn select PREEMPT_BUILD, which > selects PREEMPTION. > > (arguably we can remove the select PREEMPTION from PREEMPT_RT) > > The proposed change is not a nop because the config: PREEMPT_LAZY=y > PREEMPT_DYNAMIC=n will result in false, while it will have PREEMPTION. > > That said, I really do not agree with the change, it makes the condition > complicated for no reason. Isn't the behaviour identical to how it behaves when you choose PREEMPT_NONE/VOLUNTARY and enable/disable PREEMPT_DYNAMIC? This option is just choosing the RCU model suited for the kinds of preemption supported. -- ankur
On 2024-10-10 10:10:32 [+0200], Peter Zijlstra wrote: > On Thu, Oct 10, 2024 at 08:32:07AM +0200, Sebastian Andrzej Siewior wrote: > > On 2024-10-09 11:24:09 [-0700], Paul E. McKenney wrote: > > > In order to support systems that currently run CONFIG_PREEMPT=n that > > … > > > Or am I once again missing your point? > > > > The change is: > > | config PREEMPT_RCU > > | bool > > |- default y if PREEMPTION > > |+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > > > Now: > > - CONFIG_PREEMPT select PREEMPT_BUILD > > - PREEMPT_RT select CONFIG_PREEMPTION > > - PREEMPT_DYNAMIC selects PREEMPT_BUILD > > > > and PREEMPT_BUILD select CONFIG_PREEMPTION > > > > so in the end, this change is a nop, right? > > PREEMPT_RT selects PREEMPTION *and* has one of PREEMPT / PREEMPT_LAZY / > PREEMPT_DYNAMIC, all of which in turn select PREEMPT_BUILD, which > selects PREEMPTION. > > (arguably we can remove the select PREEMPTION from PREEMPT_RT) > > The proposed change is not a nop because the config: PREEMPT_LAZY=y > PREEMPT_DYNAMIC=n will result in false, while it will have PREEMPTION. I have a config with PREEMPT_LAZY=y PREEMPT_DYNAMIC=n and CONFIG_PREEMPT_RCU=y. I can't deselect CONFIG_PREEMPT_RCU=y. This is because LAZY selects PREEMPT_BUILD and PREEMPT_RCU selects itself once PREEMPTION is on. > That said, I really do not agree with the change, it makes the condition > complicated for no reason. Sebastian
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > On 2024-10-10 10:10:32 [+0200], Peter Zijlstra wrote: >> On Thu, Oct 10, 2024 at 08:32:07AM +0200, Sebastian Andrzej Siewior wrote: >> > On 2024-10-09 11:24:09 [-0700], Paul E. McKenney wrote: >> > > In order to support systems that currently run CONFIG_PREEMPT=n that >> > … >> > > Or am I once again missing your point? >> > >> > The change is: >> > | config PREEMPT_RCU >> > | bool >> > |- default y if PREEMPTION >> > |+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) >> > >> > Now: >> > - CONFIG_PREEMPT select PREEMPT_BUILD >> > - PREEMPT_RT select CONFIG_PREEMPTION >> > - PREEMPT_DYNAMIC selects PREEMPT_BUILD >> > >> > and PREEMPT_BUILD select CONFIG_PREEMPTION >> > >> > so in the end, this change is a nop, right? >> >> PREEMPT_RT selects PREEMPTION *and* has one of PREEMPT / PREEMPT_LAZY / >> PREEMPT_DYNAMIC, all of which in turn select PREEMPT_BUILD, which >> selects PREEMPTION. >> >> (arguably we can remove the select PREEMPTION from PREEMPT_RT) >> >> The proposed change is not a nop because the config: PREEMPT_LAZY=y >> PREEMPT_DYNAMIC=n will result in false, while it will have PREEMPTION. > > I have a config with PREEMPT_LAZY=y PREEMPT_DYNAMIC=n and > CONFIG_PREEMPT_RCU=y. > > I can't deselect CONFIG_PREEMPT_RCU=y. This is because LAZY selects > PREEMPT_BUILD and PREEMPT_RCU selects itself once PREEMPTION is on. That's odd. I have that exact configuration (PREEMPT_DYANMIC=n, PREEMPT_LAZY=y, PREEMPT_RCU=n). Can you share your .config? Ankur >> That said, I really do not agree with the change, it makes the condition >> complicated for no reason. > > Sebastian -- ankur
On 2024-10-10 10:35:25 [-0700], Ankur Arora wrote: > That's odd. I have that exact configuration (PREEMPT_DYANMIC=n, > PREEMPT_LAZY=y, PREEMPT_RCU=n). > > Can you share your .config? Sent offlist. > Ankur Sebastian
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > On 2024-10-10 10:35:25 [-0700], Ankur Arora wrote: >> That's odd. I have that exact configuration (PREEMPT_DYANMIC=n, >> PREEMPT_LAZY=y, PREEMPT_RCU=n). >> >> Can you share your .config? > > Sent offlist. Thanks. So, I tried the config and your config enables PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n. That forces PREEMPT_RCU=n. If in that config you change the preemption options to PREEMPT_LAZY=y, PREEMPT_DYNAMIC=y, we get PREEMPT_RCU=y. Is that also the behaviour you are seeing? Seems to be doing the right thing. Also, quite similar to how we handle the PREEMPT_NONE/_VOLUNTARY case. And, lazy is meant to have similar preemption behaviour as those models. -- ankur
On Thu, Oct 10, 2024 at 11:13:26AM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-10 10:10:32 [+0200], Peter Zijlstra wrote: > > On Thu, Oct 10, 2024 at 08:32:07AM +0200, Sebastian Andrzej Siewior wrote: > > > On 2024-10-09 11:24:09 [-0700], Paul E. McKenney wrote: > > > > In order to support systems that currently run CONFIG_PREEMPT=n that > > > … > > > > Or am I once again missing your point? > > > > > > The change is: > > > | config PREEMPT_RCU > > > | bool > > > |- default y if PREEMPTION > > > |+ default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > > > > > Now: > > > - CONFIG_PREEMPT select PREEMPT_BUILD > > > - PREEMPT_RT select CONFIG_PREEMPTION > > > - PREEMPT_DYNAMIC selects PREEMPT_BUILD > > > > > > and PREEMPT_BUILD select CONFIG_PREEMPTION > > > > > > so in the end, this change is a nop, right? > > > > PREEMPT_RT selects PREEMPTION *and* has one of PREEMPT / PREEMPT_LAZY / > > PREEMPT_DYNAMIC, all of which in turn select PREEMPT_BUILD, which > > selects PREEMPTION. > > > > (arguably we can remove the select PREEMPTION from PREEMPT_RT) > > > > The proposed change is not a nop because the config: PREEMPT_LAZY=y > > PREEMPT_DYNAMIC=n will result in false, while it will have PREEMPTION. > > I have a config with PREEMPT_LAZY=y PREEMPT_DYNAMIC=n and > CONFIG_PREEMPT_RCU=y. > > I can't deselect CONFIG_PREEMPT_RCU=y. This is because LAZY selects > PREEMPT_BUILD and PREEMPT_RCU selects itself once PREEMPTION is on. Oh, the entry isn't user selectable? Fix that perhaps? - bool + bool "Use preemptible RCU" Or something along those lines -- I forever forget how Kconfig works.
On 2024-10-10 12:03:08 [+0200], Peter Zijlstra wrote: > > > > I can't deselect CONFIG_PREEMPT_RCU=y. This is because LAZY selects > > PREEMPT_BUILD and PREEMPT_RCU selects itself once PREEMPTION is on. > > Oh, the entry isn't user selectable? Fix that perhaps? > > - bool > + bool "Use preemptible RCU" > > Or something along those lines -- I forever forget how Kconfig works. Oh. Well, yes. If we do this then it becomes suddenly selectable and half of the series makes sense… But as you said, this complicates things. Sebastian
On Thu, Oct 10, 2024 at 12:26:57PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-10 12:03:08 [+0200], Peter Zijlstra wrote: > > > > > > I can't deselect CONFIG_PREEMPT_RCU=y. This is because LAZY selects > > > PREEMPT_BUILD and PREEMPT_RCU selects itself once PREEMPTION is on. > > > > Oh, the entry isn't user selectable? Fix that perhaps? > > > > - bool > > + bool "Use preemptible RCU" > > > > Or something along those lines -- I forever forget how Kconfig works. > > Oh. Well, yes. If we do this then it becomes suddenly selectable and > half of the series makes sense… > But as you said, this complicates things. But then you leave it up to the user, instead of doing something quite random. This would allow you to configure PREEMPT_RCU=n despite also using PREEMPT_DYNAMIC if that is your thing. I fundamentally hate the whole randomness of the earlier proposed selection criteria. It only disables PREEMPT_RCU if you use LAZY and not also have PREEMPT_RT or PREEMPT_DYNAMIC.
On Thu, Oct 10, 2024 at 12:44:38PM +0200, Peter Zijlstra wrote: > On Thu, Oct 10, 2024 at 12:26:57PM +0200, Sebastian Andrzej Siewior wrote: > > On 2024-10-10 12:03:08 [+0200], Peter Zijlstra wrote: > > > > > > > > I can't deselect CONFIG_PREEMPT_RCU=y. This is because LAZY selects > > > > PREEMPT_BUILD and PREEMPT_RCU selects itself once PREEMPTION is on. That is not good! > > > Oh, the entry isn't user selectable? Fix that perhaps? > > > > > > - bool > > > + bool "Use preemptible RCU" > > > > > > Or something along those lines -- I forever forget how Kconfig works. > > > > Oh. Well, yes. If we do this then it becomes suddenly selectable and > > half of the series makes sense… > > But as you said, this complicates things. > > But then you leave it up to the user, instead of doing something quite > random. This would allow you to configure PREEMPT_RCU=n despite also > using PREEMPT_DYNAMIC if that is your thing. Ahem. How many users keep track of all of the Kconfig options? I doubt that this number is greater than zero. Part of the goal here needs to be to minimize the Kconfig futzing users must do. The default settings really do matter. > I fundamentally hate the whole randomness of the earlier proposed > selection criteria. It only disables PREEMPT_RCU if you use LAZY and not > also have PREEMPT_RT or PREEMPT_DYNAMIC. Not at all random. If you have PREEMPT_RT, you need preemptible RCU, so the defaults should supply it. If you have PREEMPT_DYNAMIC, presumably you would like to boot with preemption enabled, and would like it to act as if you had built the kernel to be unconditionally preemptible, so again you need preemptible RCU, and so the defaults should supply it. If you started off building a non-preemptible kernel, then you are not using one of the major distros (last I checked). There is a good chance that you have a large number of systems, and are thus deeply interested in minimizing memory cost. In which case, you need non-preemptible RCU in the new-age lazy-preemptible kernel. Hence the choice of non-preemptible RCU as the default in a kernel that, without lazy preemption, would use non-preemptible RCU. Thanx, Paul
On 2024-10-10 07:29:07 [-0700], Paul E. McKenney wrote: > If you have PREEMPT_RT, you need preemptible RCU, so the defaults should > supply it. > > If you have PREEMPT_DYNAMIC, presumably you would like to boot with > preemption enabled, and would like it to act as if you had built the > kernel to be unconditionally preemptible, so again you need preemptible > RCU, and so the defaults should supply it. > > If you started off building a non-preemptible kernel, then you are not > using one of the major distros (last I checked). There is a good chance > that you have a large number of systems, and are thus deeply interested > in minimizing memory cost. In which case, you need non-preemptible > RCU in the new-age lazy-preemptible kernel. > > Hence the choice of non-preemptible RCU as the default in a kernel that, > without lazy preemption, would use non-preemptible RCU. I *think* I slowly begin to understand. So we have LAZY and DYNAMIC enabled then and PREEMPT_RCU depends on the default choice which is either FULL (yes, please) or NONE/VOLUNTARY (no, thank you). But then if you change the model at runtime (or boottime) from (default) NONE to FULL you don't have preemptible RCU anymore. If you would like to add some relief to memory constrained systems, wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to allow to override it? > Thanx, Paul Sebastian
On Fri, Oct 11, 2024 at 10:18:47AM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-10 07:29:07 [-0700], Paul E. McKenney wrote: > > If you have PREEMPT_RT, you need preemptible RCU, so the defaults should > > supply it. > > > > If you have PREEMPT_DYNAMIC, presumably you would like to boot with > > preemption enabled, and would like it to act as if you had built the > > kernel to be unconditionally preemptible, so again you need preemptible > > RCU, and so the defaults should supply it. > > > > If you started off building a non-preemptible kernel, then you are not > > using one of the major distros (last I checked). There is a good chance > > that you have a large number of systems, and are thus deeply interested > > in minimizing memory cost. In which case, you need non-preemptible > > RCU in the new-age lazy-preemptible kernel. > > > > Hence the choice of non-preemptible RCU as the default in a kernel that, > > without lazy preemption, would use non-preemptible RCU. > > I *think* I slowly begin to understand. So we have LAZY and DYNAMIC > enabled then and PREEMPT_RCU depends on the default choice which is > either FULL (yes, please) or NONE/VOLUNTARY (no, thank you). But then if > you change the model at runtime (or boottime) from (default) NONE to > FULL you don't have preemptible RCU anymore. Almost. If you are able to change the model at boot time or at run time, then you *always* have preemptible RCU. > If you would like to add some relief to memory constrained systems, > wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to > allow to override it? Does BASE_SMALL affect anything but log buffer sizes? Either way, we would still need to avoid the larger memory footprint of preemptible RCU that shows up due to RCU readers being preempted. Besides, we are not looking to give up performance vs BASE_SMALL's "may reduce performance" help text. Yes, yes, it would simplify things to just get rid of non-preemptible RCU, but that is simply not in the cards at the moment. Thanx, Paul
On 2024-10-11 06:59:44 [-0700], Paul E. McKenney wrote: > > > If you have PREEMPT_DYNAMIC, presumably you would like to boot with > > > preemption enabled, and would like it to act as if you had built the > > > kernel to be unconditionally preemptible, so again you need preemptible > > > RCU, and so the defaults should supply it. > > > > > > If you started off building a non-preemptible kernel, then you are not > > > using one of the major distros (last I checked). There is a good chance > > > that you have a large number of systems, and are thus deeply interested > > > in minimizing memory cost. In which case, you need non-preemptible > > > RCU in the new-age lazy-preemptible kernel. > > > > > > Hence the choice of non-preemptible RCU as the default in a kernel that, > > > without lazy preemption, would use non-preemptible RCU. > > > > I *think* I slowly begin to understand. So we have LAZY and DYNAMIC > > enabled then and PREEMPT_RCU depends on the default choice which is > > either FULL (yes, please) or NONE/VOLUNTARY (no, thank you). But then if > > you change the model at runtime (or boottime) from (default) NONE to > > FULL you don't have preemptible RCU anymore. > > Almost. If you are able to change the model at boot time or at run time, > then you *always* have preemptible RCU. Okay, this eliminates PREEMPT_DYNAMIC then. With PeterZ current series, PREEMPT_LAZY (without everything else enabled) behaves as PREEMPT without the "forced" wake up for the fair class. It is preemptible after all, with preempt_disable() actually doing something. This might speak for preemptible RCU. And assuming in this condition you that "low memory overhead RCU" which is not PREEMPT_RCU. This might require a config option. > > If you would like to add some relief to memory constrained systems, > > wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to > > allow to override it? > > Does BASE_SMALL affect anything but log buffer sizes? Either way, we > would still need to avoid the larger memory footprint of preemptible > RCU that shows up due to RCU readers being preempted. It only reduces data structures where possible. So lower performance is probably due to things like futex hashmap (and others) are smaller. > Besides, we are not looking to give up performance vs BASE_SMALL's > "may reduce performance" help text. > > Yes, yes, it would simplify things to just get rid of non-preemptible RCU, > but that is simply not in the cards at the moment. Not sure what the time frame is here. If we go for LAZY and remove NONE and VOLUNTARY then making PREEMPT_RCU would make sense to lower the memory footprint (and not attaching to BASE_SMALL). Is this what you intend or did misunderstand something here? > Thanx, Paul Sebastian
On Fri, Oct 11, 2024 at 04:43:41PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-11 06:59:44 [-0700], Paul E. McKenney wrote: > > > > If you have PREEMPT_DYNAMIC, presumably you would like to boot with > > > > preemption enabled, and would like it to act as if you had built the > > > > kernel to be unconditionally preemptible, so again you need preemptible > > > > RCU, and so the defaults should supply it. > > > > > > > > If you started off building a non-preemptible kernel, then you are not > > > > using one of the major distros (last I checked). There is a good chance > > > > that you have a large number of systems, and are thus deeply interested > > > > in minimizing memory cost. In which case, you need non-preemptible > > > > RCU in the new-age lazy-preemptible kernel. > > > > > > > > Hence the choice of non-preemptible RCU as the default in a kernel that, > > > > without lazy preemption, would use non-preemptible RCU. > > > > > > I *think* I slowly begin to understand. So we have LAZY and DYNAMIC > > > enabled then and PREEMPT_RCU depends on the default choice which is > > > either FULL (yes, please) or NONE/VOLUNTARY (no, thank you). But then if > > > you change the model at runtime (or boottime) from (default) NONE to > > > FULL you don't have preemptible RCU anymore. > > > > Almost. If you are able to change the model at boot time or at run time, > > then you *always* have preemptible RCU. > > Okay, this eliminates PREEMPT_DYNAMIC then. > With PeterZ current series, PREEMPT_LAZY (without everything else > enabled) behaves as PREEMPT without the "forced" wake up for the fair > class. It is preemptible after all, with preempt_disable() actually > doing something. This might speak for preemptible RCU. > And assuming in this condition you that "low memory overhead RCU" which > is not PREEMPT_RCU. This might require a config option. The PREEMPT_DYNAMIC case seems to work well as-is for the intended users, so I don't see a need to change it. In particular, we already learned that we need to set PREEMPT_DYNAMIC=n. Yes, had I caught this in time, I would have argued against changing the default, but this was successfully slid past me. As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change than just keeping non-preemptible RCU when the Kconfig options are consistent with this being expected. If this is the case, what are the benefits of this more-intrusive change? > > > If you would like to add some relief to memory constrained systems, > > > wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to > > > allow to override it? > > > > Does BASE_SMALL affect anything but log buffer sizes? Either way, we > > would still need to avoid the larger memory footprint of preemptible > > RCU that shows up due to RCU readers being preempted. > > It only reduces data structures where possible. So lower performance is > probably due to things like futex hashmap (and others) are smaller. Which is still counterproductive for use cases other than small deep embedded systems. > > Besides, we are not looking to give up performance vs BASE_SMALL's > > "may reduce performance" help text. > > > > Yes, yes, it would simplify things to just get rid of non-preemptible RCU, > > but that is simply not in the cards at the moment. > > Not sure what the time frame is here. If we go for LAZY and remove NONE > and VOLUNTARY then making PREEMPT_RCU would make sense to lower the > memory footprint (and not attaching to BASE_SMALL). > > Is this what you intend or did misunderstand something here? My requirement is that LAZY not remove/disable/whatever non-preemptible RCU. Those currently using non-preemptible RCU should continue to be able to be able to use it, with or without LAZY. So why is this requirement a problem for you? Or am I missing your point? Thanx, Paul
On 2024-10-11 08:59:14 [-0700], Paul E. McKenney wrote:
> On Fri, Oct 11, 2024 at 04:43:41PM +0200, Sebastian Andrzej Siewior wrote:
>
> > Okay, this eliminates PREEMPT_DYNAMIC then.
> > With PeterZ current series, PREEMPT_LAZY (without everything else
> > enabled) behaves as PREEMPT without the "forced" wake up for the fair
> > class. It is preemptible after all, with preempt_disable() actually
> > doing something. This might speak for preemptible RCU.
> > And assuming in this condition you that "low memory overhead RCU" which
> > is not PREEMPT_RCU. This might require a config option.
>
> The PREEMPT_DYNAMIC case seems to work well as-is for the intended users,
> so I don't see a need to change it. In particular, we already learned
> that we need to set PREEMPT_DYNAMIC=n. Yes, had I caught this in time, I
> would have argued against changing the default, but this was successfully
> slid past me.
>
> As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change
> than just keeping non-preemptible RCU when the Kconfig options are
> consistent with this being expected. If this is the case, what are the
> benefits of this more-intrusive change?
As far as I understand you are only concerned about PREEMPT_LAZY and
everything else (PREEMPT_LAZY + PREEMPT_DYNAMIC or PREEMPT_DYNAMIC
without PREEMPT_LAZY) is fine.
In the PREEMPT_LAZY + !PREEMPT_DYNAMIC the suggested change
| config PREEMPT_RCU
| bool
| default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
| select TREE_RCU
| help
would disable PREEMPT_RCU while the default model is PREEMPT. You argue
that only people on small embedded would do such a thing and they would
like to safe additional memory.
I don't think this is always the case because the "preemptible" users
would also get this and this is an unexpected change for them.
> > > > If you would like to add some relief to memory constrained systems,
> > > > wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to
> > > > allow to override it?
> > >
> > > Does BASE_SMALL affect anything but log buffer sizes? Either way, we
> > > would still need to avoid the larger memory footprint of preemptible
> > > RCU that shows up due to RCU readers being preempted.
> >
> > It only reduces data structures where possible. So lower performance is
> > probably due to things like futex hashmap (and others) are smaller.
>
> Which is still counterproductive for use cases other than small deep
> embedded systems.
Okay, so that option is gone.
> > > Besides, we are not looking to give up performance vs BASE_SMALL's
> > > "may reduce performance" help text.
> > >
> > > Yes, yes, it would simplify things to just get rid of non-preemptible RCU,
> > > but that is simply not in the cards at the moment.
> >
> > Not sure what the time frame is here. If we go for LAZY and remove NONE
> > and VOLUNTARY then making PREEMPT_RCU would make sense to lower the
> > memory footprint (and not attaching to BASE_SMALL).
> >
> > Is this what you intend or did misunderstand something here?
>
> My requirement is that LAZY not remove/disable/whatever non-preemptible
> RCU. Those currently using non-preemptible RCU should continue to be able
> to be able to use it, with or without LAZY. So why is this requirement
> a problem for you? Or am I missing your point?
Those who were using non-preemptible RCU, whish to use LAZY_PREEPMT +
!PREEMPT_DYNAMIC should be able to disable PREEMPT_RCU only in this case.
Would the following work?
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index 8cf8a9a4d868c..2183c775e7808 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -121,6 +121,7 @@ config PREEMPT_COUNT
config PREEMPTION
bool
select PREEMPT_COUNT
+ select PREEMPT_RCU if PREEMPT_DYNAMIC
config PREEMPT_DYNAMIC
bool "Preemption behaviour defined on boot"
diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
index 3e079de0f5b43..9e4bdbbca4ff9 100644
--- a/kernel/rcu/Kconfig
+++ b/kernel/rcu/Kconfig
@@ -17,7 +17,7 @@ config TREE_RCU
smaller systems.
config PREEMPT_RCU
- bool
+ bool "Preemptible RCU"
default y if PREEMPTION
select TREE_RCU
help
@@ -91,7 +91,7 @@ config NEED_TASKS_RCU
config TASKS_RCU
bool
- default NEED_TASKS_RCU && (PREEMPTION || PREEMPT_AUTO)
+ default NEED_TASKS_RCU && PREEMPTION
select IRQ_WORK
config FORCE_TASKS_RUDE_RCU
I added TASKS_RCU to the hunk since I am not sure if you wish to follow
PREEMPTION (which is set by LAZY) or PREEMPT_RCU.
> Thanx, Paul
Sebastian
On Tue, Oct 15, 2024 at 01:22:24PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-11 08:59:14 [-0700], Paul E. McKenney wrote: > > On Fri, Oct 11, 2024 at 04:43:41PM +0200, Sebastian Andrzej Siewior wrote: > > > > > Okay, this eliminates PREEMPT_DYNAMIC then. > > > With PeterZ current series, PREEMPT_LAZY (without everything else > > > enabled) behaves as PREEMPT without the "forced" wake up for the fair > > > class. It is preemptible after all, with preempt_disable() actually > > > doing something. This might speak for preemptible RCU. > > > And assuming in this condition you that "low memory overhead RCU" which > > > is not PREEMPT_RCU. This might require a config option. > > > > The PREEMPT_DYNAMIC case seems to work well as-is for the intended users, > > so I don't see a need to change it. In particular, we already learned > > that we need to set PREEMPT_DYNAMIC=n. Yes, had I caught this in time, I > > would have argued against changing the default, but this was successfully > > slid past me. > > > > As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change > > than just keeping non-preemptible RCU when the Kconfig options are > > consistent with this being expected. If this is the case, what are the > > benefits of this more-intrusive change? > > As far as I understand you are only concerned about PREEMPT_LAZY and > everything else (PREEMPT_LAZY + PREEMPT_DYNAMIC or PREEMPT_DYNAMIC > without PREEMPT_LAZY) is fine. > In the PREEMPT_LAZY + !PREEMPT_DYNAMIC the suggested change > > | config PREEMPT_RCU > | bool > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > | select TREE_RCU > | help > > would disable PREEMPT_RCU while the default model is PREEMPT. You argue > that only people on small embedded would do such a thing and they would > like to safe additional memory. I am more worried about large datacenter deployments than small embedded systems. Larger systems, but various considerations often limit the amount of memory on a given system. > I don't think this is always the case because the "preemptible" users > would also get this and this is an unexpected change for them. Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? As conceived last time around, the change would affect only kernels built with one of the other of those two Kconfig options, which will not be users expecting preemption. > > > > > If you would like to add some relief to memory constrained systems, > > > > > wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to > > > > > allow to override it? > > > > > > > > Does BASE_SMALL affect anything but log buffer sizes? Either way, we > > > > would still need to avoid the larger memory footprint of preemptible > > > > RCU that shows up due to RCU readers being preempted. > > > > > > It only reduces data structures where possible. So lower performance is > > > probably due to things like futex hashmap (and others) are smaller. > > > > Which is still counterproductive for use cases other than small deep > > embedded systems. > > Okay, so that option is gone. It was worth a look, so thank you! > > > > Besides, we are not looking to give up performance vs BASE_SMALL's > > > > "may reduce performance" help text. > > > > > > > > Yes, yes, it would simplify things to just get rid of non-preemptible RCU, > > > > but that is simply not in the cards at the moment. > > > > > > Not sure what the time frame is here. If we go for LAZY and remove NONE > > > and VOLUNTARY then making PREEMPT_RCU would make sense to lower the > > > memory footprint (and not attaching to BASE_SMALL). > > > > > > Is this what you intend or did misunderstand something here? > > > > My requirement is that LAZY not remove/disable/whatever non-preemptible > > RCU. Those currently using non-preemptible RCU should continue to be able > > to be able to use it, with or without LAZY. So why is this requirement > > a problem for you? Or am I missing your point? > > Those who were using non-preemptible RCU, whish to use LAZY_PREEPMT + > !PREEMPT_DYNAMIC should be able to disable PREEMPT_RCU only in this case. > Would the following work? > > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt > index 8cf8a9a4d868c..2183c775e7808 100644 > --- a/kernel/Kconfig.preempt > +++ b/kernel/Kconfig.preempt > @@ -121,6 +121,7 @@ config PREEMPT_COUNT > config PREEMPTION > bool > select PREEMPT_COUNT > + select PREEMPT_RCU if PREEMPT_DYNAMIC > > config PREEMPT_DYNAMIC > bool "Preemption behaviour defined on boot" > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > index 3e079de0f5b43..9e4bdbbca4ff9 100644 > --- a/kernel/rcu/Kconfig > +++ b/kernel/rcu/Kconfig > @@ -17,7 +17,7 @@ config TREE_RCU > smaller systems. > > config PREEMPT_RCU > - bool > + bool "Preemptible RCU" > default y if PREEMPTION > select TREE_RCU > help > @@ -91,7 +91,7 @@ config NEED_TASKS_RCU If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be far better to make PREEMPT_RCU depend on neither of those being set. That would leave the RCU Kconfig settings fully automatic, and this automation is not to be abandoned lightly. > config TASKS_RCU > bool > - default NEED_TASKS_RCU && (PREEMPTION || PREEMPT_AUTO) > + default NEED_TASKS_RCU && PREEMPTION > select IRQ_WORK > > config FORCE_TASKS_RUDE_RCU > > I added TASKS_RCU to the hunk since I am not sure if you wish to follow > PREEMPTION (which is set by LAZY) or PREEMPT_RCU. TASKS_RCU needs to be selected when there is preemption of any kind, lazy or otherwise, regardless of the settign of PREEMPT_RCU. The current substition of vanilla RCU for Tasks RCU works only in kernels that are guaranteed non-preemptible, which does not include kernels built with lazy preemption. Thanx, Paul
On 2024-10-15 16:11:55 [-0700], Paul E. McKenney wrote: > > | config PREEMPT_RCU > > | bool > > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > | select TREE_RCU > > | help > > > > would disable PREEMPT_RCU while the default model is PREEMPT. You argue > > that only people on small embedded would do such a thing and they would > > like to safe additional memory. > > I am more worried about large datacenter deployments than small embedded > systems. Larger systems, but various considerations often limit the > amount of memory on a given system. okay. > > I don't think this is always the case because the "preemptible" users > > would also get this and this is an unexpected change for them. > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? no, not yet. It is only adding PREEMPT_LAZY as new model, next to PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule. > As conceived last time around, the change would affect only kernels > built with one of the other of those two Kconfig options, which will > not be users expecting preemption. If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes right now. > > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt > > index 8cf8a9a4d868c..2183c775e7808 100644 > > --- a/kernel/Kconfig.preempt > > +++ b/kernel/Kconfig.preempt > > @@ -121,6 +121,7 @@ config PREEMPT_COUNT > > config PREEMPTION > > bool > > select PREEMPT_COUNT > > + select PREEMPT_RCU if PREEMPT_DYNAMIC > > > > config PREEMPT_DYNAMIC > > bool "Preemption behaviour defined on boot" > > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > > index 3e079de0f5b43..9e4bdbbca4ff9 100644 > > --- a/kernel/rcu/Kconfig > > +++ b/kernel/rcu/Kconfig > > @@ -17,7 +17,7 @@ config TREE_RCU > > smaller systems. > > > > config PREEMPT_RCU > > - bool > > + bool "Preemptible RCU" > > default y if PREEMPTION > > select TREE_RCU > > help > > @@ -91,7 +91,7 @@ config NEED_TASKS_RCU > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be > far better to make PREEMPT_RCU depend on neither of those being set. > That would leave the RCU Kconfig settings fully automatic, and this > automation is not to be abandoned lightly. Yes, that was my intention - only to make is selectable with LAZY-preemption enabled but without dynamic. So you are not complete against it. > > config TASKS_RCU > > bool > > - default NEED_TASKS_RCU && (PREEMPTION || PREEMPT_AUTO) > > + default NEED_TASKS_RCU && PREEMPTION > > select IRQ_WORK > > > > config FORCE_TASKS_RUDE_RCU > > > > I added TASKS_RCU to the hunk since I am not sure if you wish to follow > > PREEMPTION (which is set by LAZY) or PREEMPT_RCU. > > TASKS_RCU needs to be selected when there is preemption of any kind, > lazy or otherwise, regardless of the settign of PREEMPT_RCU. Okay. In that case PREEMPT_AUTO can be removed. > The current substition of vanilla RCU for Tasks RCU works only in > kernels that are guaranteed non-preemptible, which does not include > kernels built with lazy preemption. > > Thanx, Paul Sebastian
On Thu, Oct 17, 2024 at 09:07:10AM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-15 16:11:55 [-0700], Paul E. McKenney wrote: > > > | config PREEMPT_RCU > > > | bool > > > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > > | select TREE_RCU > > > | help > > > > > > would disable PREEMPT_RCU while the default model is PREEMPT. You argue > > > that only people on small embedded would do such a thing and they would > > > like to safe additional memory. > > > > I am more worried about large datacenter deployments than small embedded > > systems. Larger systems, but various considerations often limit the > > amount of memory on a given system. > > okay. > > > > I don't think this is always the case because the "preemptible" users > > > would also get this and this is an unexpected change for them. > > > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? > no, not yet. It is only adding PREEMPT_LAZY as new model, next to > PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule. > > > As conceived last time around, the change would affect only kernels > > built with one of the other of those two Kconfig options, which will > > not be users expecting preemption. > > If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes > right now. Good, thank you! Presumably PREEMPT_NONE=y && PREEMPT_LAZY=y enables lazy preemption, but retains non-preemptible RCU. > > > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt > > > index 8cf8a9a4d868c..2183c775e7808 100644 > > > --- a/kernel/Kconfig.preempt > > > +++ b/kernel/Kconfig.preempt > > > @@ -121,6 +121,7 @@ config PREEMPT_COUNT > > > config PREEMPTION > > > bool > > > select PREEMPT_COUNT > > > + select PREEMPT_RCU if PREEMPT_DYNAMIC > > > > > > config PREEMPT_DYNAMIC > > > bool "Preemption behaviour defined on boot" > > > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > > > index 3e079de0f5b43..9e4bdbbca4ff9 100644 > > > --- a/kernel/rcu/Kconfig > > > +++ b/kernel/rcu/Kconfig > > > @@ -17,7 +17,7 @@ config TREE_RCU > > > smaller systems. > > > > > > config PREEMPT_RCU > > > - bool > > > + bool "Preemptible RCU" > > > default y if PREEMPTION > > > select TREE_RCU > > > help > > > @@ -91,7 +91,7 @@ config NEED_TASKS_RCU > > > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be > > far better to make PREEMPT_RCU depend on neither of those being set. > > That would leave the RCU Kconfig settings fully automatic, and this > > automation is not to be abandoned lightly. > > Yes, that was my intention - only to make is selectable with > LAZY-preemption enabled but without dynamic. > So you are not complete against it. Help me out here. In what situation is it beneficial to make PREEMPT_RCU visible, given that PREEMPT_NONE, PREEMPT_VOLUNTARY, PREEMPT, and PREEMPT_FULL already take care of this automatically? > > > config TASKS_RCU > > > bool > > > - default NEED_TASKS_RCU && (PREEMPTION || PREEMPT_AUTO) > > > + default NEED_TASKS_RCU && PREEMPTION > > > select IRQ_WORK > > > > > > config FORCE_TASKS_RUDE_RCU > > > > > > I added TASKS_RCU to the hunk since I am not sure if you wish to follow > > > PREEMPTION (which is set by LAZY) or PREEMPT_RCU. > > > > TASKS_RCU needs to be selected when there is preemption of any kind, > > lazy or otherwise, regardless of the settign of PREEMPT_RCU. > > Okay. In that case PREEMPT_AUTO can be removed. Makes sense to me! Thanx, Paul > > The current substition of vanilla RCU for Tasks RCU works only in > > kernels that are guaranteed non-preemptible, which does not include > > kernels built with lazy preemption. > > > > Thanx, Paul > > Sebastian
On 2024-10-18 10:38:15 [-0700], Paul E. McKenney wrote: > > > > I don't think this is always the case because the "preemptible" users > > > > would also get this and this is an unexpected change for them. > > > > > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? > > no, not yet. It is only adding PREEMPT_LAZY as new model, next to > > PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule. > > > > > As conceived last time around, the change would affect only kernels > > > built with one of the other of those two Kconfig options, which will > > > not be users expecting preemption. > > > > If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes > > right now. > > Good, thank you! > > Presumably PREEMPT_NONE=y && PREEMPT_LAZY=y enables lazy preemption, > but retains non-preemptible RCU. PREEMPT_NONE=y && PREEMPT_LAZY=y is exclusive. Either NONE or LAZY. > > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be > > > far better to make PREEMPT_RCU depend on neither of those being set. > > > That would leave the RCU Kconfig settings fully automatic, and this > > > automation is not to be abandoned lightly. > > > > Yes, that was my intention - only to make is selectable with > > LAZY-preemption enabled but without dynamic. > > So you are not complete against it. > > Help me out here. In what situation is it beneficial to make PREEMPT_RCU > visible, given that PREEMPT_NONE, PREEMPT_VOLUNTARY, PREEMPT, and > PREEMPT_FULL already take care of this automatically? We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one). This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST. Ignore LAZIEST. PREEMPT_RT is a on/ off bool. Based on my understanding so far, you have nothing to worry about. With NONE + VOLUNTARY removed in favor of LAZY or without the removal (yet) you ask yourself what happens to those using NONE, go to LAZY and want to stay with !PREEMPT_RCU, right? With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now. And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/ VOLUNTARY users and want !PREEMPT_RCU. This could be true but it could also attract people from PREEMPT which expect additional performance gain due to LAZY and the same "preemption" level. Additionally if PREEMPT gets removed because LAZY turns out to be superior then PREEMPT_DYNAMIC makes probably no sense since there is nothing to switch from/ to. Therefore I would suggest to make PREEMPT_RCU - selectable for LAZY && !PREEMPT_DYNAMIC, default yes - selected for LAZY && PREEMPT_DYNAMIC - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with !PREEMPT_DYNAMIC) Does this make sense to you? > Thanx, Paul Sebastian
On Mon, Oct 21, 2024 at 01:27:55PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-18 10:38:15 [-0700], Paul E. McKenney wrote: > > > > > I don't think this is always the case because the "preemptible" users > > > > > would also get this and this is an unexpected change for them. > > > > > > > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? > > > no, not yet. It is only adding PREEMPT_LAZY as new model, next to > > > PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule. > > > > > > > As conceived last time around, the change would affect only kernels > > > > built with one of the other of those two Kconfig options, which will > > > > not be users expecting preemption. > > > > > > If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes > > > right now. > > > > Good, thank you! > > > > Presumably PREEMPT_NONE=y && PREEMPT_LAZY=y enables lazy preemption, > > but retains non-preemptible RCU. > > PREEMPT_NONE=y && PREEMPT_LAZY=y is exclusive. Either NONE or LAZY. Ah, I was thinking in terms of the previous lazy-preemption patch series, and just now got around to looking at the new one. Apologies for my confusion! > > > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be > > > > far better to make PREEMPT_RCU depend on neither of those being set. > > > > That would leave the RCU Kconfig settings fully automatic, and this > > > > automation is not to be abandoned lightly. > > > > > > Yes, that was my intention - only to make is selectable with > > > LAZY-preemption enabled but without dynamic. > > > So you are not complete against it. > > > > Help me out here. In what situation is it beneficial to make PREEMPT_RCU > > visible, given that PREEMPT_NONE, PREEMPT_VOLUNTARY, PREEMPT, and > > PREEMPT_FULL already take care of this automatically? > > We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one). > > This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST. > Ignore LAZIEST. PREEMPT_RT is a on/ off bool. In terms of preemptibility, isn't the order from least to most preemptible NONE, VOLUNTARY, LAZIEST, LAZY, PREEMPT, and PREEMPT_RT? After all, PREEMPT will preempt more aggressively than will LAZY which in turn preempts more aggressively than LAZIEST. And I finally do see the later patch in Peter's series that removes PREEMPT_RT from the choice. Plus I need to look more at LAZIEST in order to work out whether Peter's suckage is our robustness. ;-) > Based on my understanding so far, you have nothing to worry about. > > With NONE + VOLUNTARY removed in favor of LAZY or without the removal > (yet) you ask yourself what happens to those using NONE, go to LAZY and > want to stay with !PREEMPT_RCU, right? > With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now. > And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/ > VOLUNTARY users and want !PREEMPT_RCU. Yes. > This could be true but it could also attract people from PREEMPT which > expect additional performance gain due to LAZY and the same "preemption" > level. Additionally if PREEMPT gets removed because LAZY turns out to be > superior then PREEMPT_DYNAMIC makes probably no sense since there is > nothing to switch from/ to. We definitely have users that would migrate from NONE to LAZY. Shouldn't their needs outweigh the possible future users that might (or might not) find that (1) LAZY might be preferable to PREEMPT for some users and (2) That those users would prefer that RCU be preemptible? > Therefore I would suggest to make PREEMPT_RCU > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > - selected for LAZY && PREEMPT_DYNAMIC > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > !PREEMPT_DYNAMIC) > > Does this make sense to you? Not really. At the very least, default no. Unless LAZIEST makes the most sense for us (which will take time to figure out), in which case make PREMPT_RCU: - hard-defined =n for LAZIEST. - selectable for LAZY && !PREEMPT_DYNAMIC, default yes - selected for LAZY && PREEMPT_DYNAMIC - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with !PREEMPT_DYNAMIC) Or am I still missing some aspect of this series? Thanx, Paul
On 2024-10-21 09:48:03 [-0700], Paul E. McKenney wrote: > > We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one). > > > > This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST. > > Ignore LAZIEST. PREEMPT_RT is a on/ off bool. > > In terms of preemptibility, isn't the order from least to most preemptible > NONE, VOLUNTARY, LAZIEST, LAZY, PREEMPT, and PREEMPT_RT? After all, > PREEMPT will preempt more aggressively than will LAZY which in turn > preempts more aggressively than LAZIEST. > > And I finally do see the later patch in Peter's series that removes > PREEMPT_RT from the choice. Plus I need to look more at LAZIEST in > order to work out whether Peter's suckage is our robustness. ;-) For LAZIEST PeterZ added "do we want this?". I haven't tested this but since there is no forced preemption at all, it should be what is NONE without cond_resched() & friends. So I don't know if it stays, I don't think so. > > Based on my understanding so far, you have nothing to worry about. > > > > With NONE + VOLUNTARY removed in favor of LAZY or without the removal > > (yet) you ask yourself what happens to those using NONE, go to LAZY and > > want to stay with !PREEMPT_RCU, right? > > With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now. > > And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/ > > VOLUNTARY users and want !PREEMPT_RCU. > > Yes. > > > This could be true but it could also attract people from PREEMPT which > > expect additional performance gain due to LAZY and the same "preemption" > > level. Additionally if PREEMPT gets removed because LAZY turns out to be > > superior then PREEMPT_DYNAMIC makes probably no sense since there is > > nothing to switch from/ to. > > We definitely have users that would migrate from NONE to LAZY. Shouldn't > their needs outweigh the possible future users that might (or might not) > find that (1) LAZY might be preferable to PREEMPT for some users and > (2) That those users would prefer that RCU be preemptible? Yes. I have no idea which of those two (PREEMPT_RCU vs !PREEMPT_RCU) is to be preferred. Therefore I'm suggesting to make configurable here. If you have a benchmark for memory consumption or anything else of interest, I could throw it a box or two to get some numbers. I've been looking at free memory at boot and this was almost the same (+- noise). > > Therefore I would suggest to make PREEMPT_RCU > > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > > - selected for LAZY && PREEMPT_DYNAMIC > > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > > !PREEMPT_DYNAMIC) > > > > Does this make sense to you? > > Not really. At the very least, default no. > > Unless LAZIEST makes the most sense for us (which will take time to > figure out), in which case make PREMPT_RCU: > > - hard-defined =n for LAZIEST. > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > - selected for LAZY && PREEMPT_DYNAMIC > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > !PREEMPT_DYNAMIC) > > Or am I still missing some aspect of this series? no, that is perfect. > Thanx, Paul Sebastian
On Tue, Oct 22, 2024 at 04:09:33PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-21 09:48:03 [-0700], Paul E. McKenney wrote: > > > We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one). > > > > > > This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST. > > > Ignore LAZIEST. PREEMPT_RT is a on/ off bool. > > > > In terms of preemptibility, isn't the order from least to most preemptible > > NONE, VOLUNTARY, LAZIEST, LAZY, PREEMPT, and PREEMPT_RT? After all, > > PREEMPT will preempt more aggressively than will LAZY which in turn > > preempts more aggressively than LAZIEST. > > > > And I finally do see the later patch in Peter's series that removes > > PREEMPT_RT from the choice. Plus I need to look more at LAZIEST in > > order to work out whether Peter's suckage is our robustness. ;-) > > For LAZIEST PeterZ added "do we want this?". I haven't tested this but > since there is no forced preemption at all, it should be what is NONE > without cond_resched() & friends. So I don't know if it stays, I don't > think so. I don't know of a compelling reason for it to. > > > Based on my understanding so far, you have nothing to worry about. > > > > > > With NONE + VOLUNTARY removed in favor of LAZY or without the removal > > > (yet) you ask yourself what happens to those using NONE, go to LAZY and > > > want to stay with !PREEMPT_RCU, right? > > > With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now. > > > And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/ > > > VOLUNTARY users and want !PREEMPT_RCU. > > > > Yes. > > > > > This could be true but it could also attract people from PREEMPT which > > > expect additional performance gain due to LAZY and the same "preemption" > > > level. Additionally if PREEMPT gets removed because LAZY turns out to be > > > superior then PREEMPT_DYNAMIC makes probably no sense since there is > > > nothing to switch from/ to. > > > > We definitely have users that would migrate from NONE to LAZY. Shouldn't > > their needs outweigh the possible future users that might (or might not) > > find that (1) LAZY might be preferable to PREEMPT for some users and > > (2) That those users would prefer that RCU be preemptible? > > Yes. I have no idea which of those two (PREEMPT_RCU vs !PREEMPT_RCU) is > to be preferred. Therefore I'm suggesting to make configurable here. As Ankur noted, the original intent was to move people from both PREEMPT_NONE and PREEMPT_VOLUNTARY to lazy preemption. This strongly suggests setting the value of PREEMPT_RCU to n. Not just the default, but the value. We need to have a definite non-speculative case for forcing people to once again worry about RCU preemptibility, and I know of no such case. > If you have a benchmark for memory consumption or anything else of > interest, I could throw it a box or two to get some numbers. I've been > looking at free memory at boot and this was almost the same (+- noise). Unfortunately, the benchmark is the fleet and all of the various non-public applications that run on it. :-( > > > Therefore I would suggest to make PREEMPT_RCU > > > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > > > - selected for LAZY && PREEMPT_DYNAMIC > > > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > > > !PREEMPT_DYNAMIC) > > > > > > Does this make sense to you? > > > > Not really. At the very least, default no. > > > > Unless LAZIEST makes the most sense for us (which will take time to > > figure out), in which case make PREMPT_RCU: > > > > - hard-defined =n for LAZIEST. > > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > > - selected for LAZY && PREEMPT_DYNAMIC > > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > > !PREEMPT_DYNAMIC) > > > > Or am I still missing some aspect of this series? > > no, that is perfect. And assuming LAZIEST is not to be with us much longer, this becomes: - hard-defined to "no" for LAZY && !PREEMPT_DYNAMIC, just like NONE or VOLUNTARY with !PREEMPT_DYNAMIC. - selected for LAZY && PREEMPT_DYNAMIC - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with !PREEMPT_DYNAMIC) Fair enough? Thanx, Paul
On 2024-10-22 16:54:11 [-0700], Paul E. McKenney wrote: > > Yes. I have no idea which of those two (PREEMPT_RCU vs !PREEMPT_RCU) is > > to be preferred. Therefore I'm suggesting to make configurable here. > > As Ankur noted, the original intent was to move people from both > PREEMPT_NONE and PREEMPT_VOLUNTARY to lazy preemption. This strongly > suggests setting the value of PREEMPT_RCU to n. Not just the default, > but the value. We need to have a definite non-speculative case for > forcing people to once again worry about RCU preemptibility, and I know > of no such case. okay. > > If you have a benchmark for memory consumption or anything else of > > interest, I could throw it a box or two to get some numbers. I've been > > looking at free memory at boot and this was almost the same (+- noise). > > Unfortunately, the benchmark is the fleet and all of the various > non-public applications that run on it. :-( I see. > > > > Therefore I would suggest to make PREEMPT_RCU > > > > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > > > > - selected for LAZY && PREEMPT_DYNAMIC > > > > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > > > > !PREEMPT_DYNAMIC) > > > > > > > > Does this make sense to you? > > > > > > Not really. At the very least, default no. > > > > > > Unless LAZIEST makes the most sense for us (which will take time to > > > figure out), in which case make PREMPT_RCU: > > > > > > - hard-defined =n for LAZIEST. > > > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > > > - selected for LAZY && PREEMPT_DYNAMIC > > > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > > > !PREEMPT_DYNAMIC) > > > > > > Or am I still missing some aspect of this series? > > > > no, that is perfect. > > And assuming LAZIEST is not to be with us much longer, this becomes: > > - hard-defined to "no" for LAZY && !PREEMPT_DYNAMIC, just like > NONE or VOLUNTARY with !PREEMPT_DYNAMIC. > - selected for LAZY && PREEMPT_DYNAMIC > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > !PREEMPT_DYNAMIC) > > Fair enough? Guess this hard no and worry later makes sense. > Thanx, Paul Sebastian
Paul E. McKenney <paulmck@kernel.org> writes: > On Mon, Oct 21, 2024 at 01:27:55PM +0200, Sebastian Andrzej Siewior wrote: >> On 2024-10-18 10:38:15 [-0700], Paul E. McKenney wrote: >> > > > > I don't think this is always the case because the "preemptible" users >> > > > > would also get this and this is an unexpected change for them. >> > > > >> > > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? >> > > no, not yet. It is only adding PREEMPT_LAZY as new model, next to >> > > PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule. >> > > >> > > > As conceived last time around, the change would affect only kernels >> > > > built with one of the other of those two Kconfig options, which will >> > > > not be users expecting preemption. >> > > >> > > If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes >> > > right now. >> > >> > Good, thank you! >> > >> > Presumably PREEMPT_NONE=y && PREEMPT_LAZY=y enables lazy preemption, >> > but retains non-preemptible RCU. >> >> PREEMPT_NONE=y && PREEMPT_LAZY=y is exclusive. Either NONE or LAZY. > > Ah, I was thinking in terms of the previous lazy-preemption patch series, > and just now got around to looking at the new one. Apologies for my > confusion! Minor point, but you might be thinking of PREEMPT_AUTO=y && PREEMPT_LAZY=y. >> > > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be >> > > > far better to make PREEMPT_RCU depend on neither of those being set. >> > > > That would leave the RCU Kconfig settings fully automatic, and this >> > > > automation is not to be abandoned lightly. >> > > >> > > Yes, that was my intention - only to make is selectable with >> > > LAZY-preemption enabled but without dynamic. >> > > So you are not complete against it. >> > >> > Help me out here. In what situation is it beneficial to make PREEMPT_RCU >> > visible, given that PREEMPT_NONE, PREEMPT_VOLUNTARY, PREEMPT, and >> > PREEMPT_FULL already take care of this automatically? >> >> We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one). >> >> This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST. >> Ignore LAZIEST. PREEMPT_RT is a on/ off bool. > > In terms of preemptibility, isn't the order from least to most preemptible > NONE, VOLUNTARY, LAZIEST, LAZY, PREEMPT, and PREEMPT_RT? After all, > PREEMPT will preempt more aggressively than will LAZY which in turn > preempts more aggressively than LAZIEST. > > And I finally do see the later patch in Peter's series that removes > PREEMPT_RT from the choice. Plus I need to look more at LAZIEST in > order to work out whether Peter's suckage is our robustness. ;-) > >> Based on my understanding so far, you have nothing to worry about. >> >> With NONE + VOLUNTARY removed in favor of LAZY or without the removal >> (yet) you ask yourself what happens to those using NONE, go to LAZY and >> want to stay with !PREEMPT_RCU, right? >> With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now. >> And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/ >> VOLUNTARY users and want !PREEMPT_RCU. > > Yes. > >> This could be true but it could also attract people from PREEMPT which >> expect additional performance gain due to LAZY and the same "preemption" >> level. Additionally if PREEMPT gets removed because LAZY turns out to be >> superior then PREEMPT_DYNAMIC makes probably no sense since there is >> nothing to switch from/ to. > > We definitely have users that would migrate from NONE to LAZY. Shouldn't Indeed. This was the original intent behind Thomas's proposal of preempt lazy. > their needs outweigh the possible future users that might (or might not) > find that (1) LAZY might be preferable to PREEMPT for some users and > (2) That those users would prefer that RCU be preemptible? Users who care about low latency already have perfectly good options: PREEMPT, PREEMPT_DYNAMIC and now PREEMPT_RT. I don't see the point of elevating low latency needs in all preemption models -- even those which are meant to be througput oriented. >> Therefore I would suggest to make PREEMPT_RCU >> - selectable for LAZY && !PREEMPT_DYNAMIC, default yes >> - selected for LAZY && PREEMPT_DYNAMIC >> - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with >> !PREEMPT_DYNAMIC) >> >> Does this make sense to you? > > Not really. At the very least, default no. > > Unless LAZIEST makes the most sense for us (which will take time to > figure out), in which case make PREMPT_RCU: I don't think laziest was ever meant to be a serious option. Peter mentioned that he'll be dropping it: https://lore.kernel.org/lkml/20241008144049.GF14587@noisy.programming.kicks-ass.net/ Ankur > - hard-defined =n for LAZIEST. > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > - selected for LAZY && PREEMPT_DYNAMIC > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > !PREEMPT_DYNAMIC) > > Or am I still missing some aspect of this series? > > Thanx, Paul -- ankur
On Mon, Oct 21, 2024 at 12:20:58PM -0700, Ankur Arora wrote: > > Paul E. McKenney <paulmck@kernel.org> writes: > > > On Mon, Oct 21, 2024 at 01:27:55PM +0200, Sebastian Andrzej Siewior wrote: > >> On 2024-10-18 10:38:15 [-0700], Paul E. McKenney wrote: > >> > > > > I don't think this is always the case because the "preemptible" users > >> > > > > would also get this and this is an unexpected change for them. > >> > > > > >> > > > Is this series now removing PREEMPT_NONE and PREEMPT_VOLUNTARY? > >> > > no, not yet. It is only adding PREEMPT_LAZY as new model, next to > >> > > PREEMPT_NONE and PREEMPT_VOLUNTARY. But is is likely to be on schedule. > >> > > > >> > > > As conceived last time around, the change would affect only kernels > >> > > > built with one of the other of those two Kconfig options, which will > >> > > > not be users expecting preemption. > >> > > > >> > > If you continue to use PREEMPT_NONE/ PREEMPT_VOLUNTARY nothing changes > >> > > right now. > >> > > >> > Good, thank you! > >> > > >> > Presumably PREEMPT_NONE=y && PREEMPT_LAZY=y enables lazy preemption, > >> > but retains non-preemptible RCU. > >> > >> PREEMPT_NONE=y && PREEMPT_LAZY=y is exclusive. Either NONE or LAZY. > > > > Ah, I was thinking in terms of the previous lazy-preemption patch series, > > and just now got around to looking at the new one. Apologies for my > > confusion! > > Minor point, but you might be thinking of PREEMPT_AUTO=y && PREEMPT_LAZY=y. Entirely possible. > >> > > > If PREEMPT_NONE and PREEMPT_VOLUNTARY are still around, it would be > >> > > > far better to make PREEMPT_RCU depend on neither of those being set. > >> > > > That would leave the RCU Kconfig settings fully automatic, and this > >> > > > automation is not to be abandoned lightly. > >> > > > >> > > Yes, that was my intention - only to make is selectable with > >> > > LAZY-preemption enabled but without dynamic. > >> > > So you are not complete against it. > >> > > >> > Help me out here. In what situation is it beneficial to make PREEMPT_RCU > >> > visible, given that PREEMPT_NONE, PREEMPT_VOLUNTARY, PREEMPT, and > >> > PREEMPT_FULL already take care of this automatically? > >> > >> We have now NONE, VOLUNTARY, PREEMPT, PREEMPT_RT (as in choose one). > >> > >> This series changes it to NONE, VOLUNTARY, PREEMPT, LAZY, LAZIEST. > >> Ignore LAZIEST. PREEMPT_RT is a on/ off bool. > > > > In terms of preemptibility, isn't the order from least to most preemptible > > NONE, VOLUNTARY, LAZIEST, LAZY, PREEMPT, and PREEMPT_RT? After all, > > PREEMPT will preempt more aggressively than will LAZY which in turn > > preempts more aggressively than LAZIEST. > > > > And I finally do see the later patch in Peter's series that removes > > PREEMPT_RT from the choice. Plus I need to look more at LAZIEST in > > order to work out whether Peter's suckage is our robustness. ;-) > > > >> Based on my understanding so far, you have nothing to worry about. > >> > >> With NONE + VOLUNTARY removed in favor of LAZY or without the removal > >> (yet) you ask yourself what happens to those using NONE, go to LAZY and > >> want to stay with !PREEMPT_RCU, right? > >> With LAZY and !PREEMPT_DYNAMIC there is still PREEMPT_RCU as of now. > >> And you say people using !PREEMPT_DYNAMIC + LAZY are the old NONE/ > >> VOLUNTARY users and want !PREEMPT_RCU. > > > > Yes. > > > >> This could be true but it could also attract people from PREEMPT which > >> expect additional performance gain due to LAZY and the same "preemption" > >> level. Additionally if PREEMPT gets removed because LAZY turns out to be > >> superior then PREEMPT_DYNAMIC makes probably no sense since there is > >> nothing to switch from/ to. > > > > We definitely have users that would migrate from NONE to LAZY. Shouldn't > > Indeed. This was the original intent behind Thomas's proposal of preempt > lazy. Whew!!! That is my recollection as well. > > their needs outweigh the possible future users that might (or might not) > > find that (1) LAZY might be preferable to PREEMPT for some users and > > (2) That those users would prefer that RCU be preemptible? > > Users who care about low latency already have perfectly good options: > PREEMPT, PREEMPT_DYNAMIC and now PREEMPT_RT. > > I don't see the point of elevating low latency needs in all preemption > models -- even those which are meant to be througput oriented. Agreed! > >> Therefore I would suggest to make PREEMPT_RCU > >> - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > >> - selected for LAZY && PREEMPT_DYNAMIC > >> - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > >> !PREEMPT_DYNAMIC) > >> > >> Does this make sense to you? > > > > Not really. At the very least, default no. > > > > Unless LAZIEST makes the most sense for us (which will take time to > > figure out), in which case make PREMPT_RCU: > > I don't think laziest was ever meant to be a serious option. > > Peter mentioned that he'll be dropping it: > https://lore.kernel.org/lkml/20241008144049.GF14587@noisy.programming.kicks-ass.net/ Well, if Peter is going to drop it, I won't be evaluating it! ;-) Thanx, Paul > Ankur > > > - hard-defined =n for LAZIEST. > > - selectable for LAZY && !PREEMPT_DYNAMIC, default yes > > - selected for LAZY && PREEMPT_DYNAMIC > > - the current unchanged state for NONE, VOLUNTARY, PREEMPT (with > > !PREEMPT_DYNAMIC) > > > > Or am I still missing some aspect of this series? > > > > Thanx, Paul > > > -- > ankur
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > On 2024-10-11 08:59:14 [-0700], Paul E. McKenney wrote: >> On Fri, Oct 11, 2024 at 04:43:41PM +0200, Sebastian Andrzej Siewior wrote: >> >> > Okay, this eliminates PREEMPT_DYNAMIC then. >> > With PeterZ current series, PREEMPT_LAZY (without everything else >> > enabled) behaves as PREEMPT without the "forced" wake up for the fair >> > class. It is preemptible after all, with preempt_disable() actually >> > doing something. This might speak for preemptible RCU. >> > And assuming in this condition you that "low memory overhead RCU" which >> > is not PREEMPT_RCU. This might require a config option. >> >> The PREEMPT_DYNAMIC case seems to work well as-is for the intended users, >> so I don't see a need to change it. In particular, we already learned >> that we need to set PREEMPT_DYNAMIC=n. Yes, had I caught this in time, I >> would have argued against changing the default, but this was successfully >> slid past me. >> >> As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change >> than just keeping non-preemptible RCU when the Kconfig options are >> consistent with this being expected. If this is the case, what are the >> benefits of this more-intrusive change? > > As far as I understand you are only concerned about PREEMPT_LAZY and > everything else (PREEMPT_LAZY + PREEMPT_DYNAMIC or PREEMPT_DYNAMIC > without PREEMPT_LAZY) is fine. > In the PREEMPT_LAZY + !PREEMPT_DYNAMIC the suggested change > > | config PREEMPT_RCU > | bool > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > | select TREE_RCU > | help > > would disable PREEMPT_RCU while the default model is PREEMPT. You argue With PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n, isn't the default model PREEMPT_LAZY, which has PREEMPTION=y, but PREEMPT=n? > that only people on small embedded would do such a thing and they would > like to safe additional memory. > > I don't think this is always the case because the "preemptible" users > would also get this and this is an unexpected change for them. Can you clarify this? The intent with lazy is to be preemptible but preempt less often. In that it is meant to be quite different from CONFIG_PREEMPT. Ankur >> > > > If you would like to add some relief to memory constrained systems, >> > > > wouldn't BASE_SMALL be something you could hook to? With EXPERT_RCU to >> > > > allow to override it? >> > > >> > > Does BASE_SMALL affect anything but log buffer sizes? Either way, we >> > > would still need to avoid the larger memory footprint of preemptible >> > > RCU that shows up due to RCU readers being preempted. >> > >> > It only reduces data structures where possible. So lower performance is >> > probably due to things like futex hashmap (and others) are smaller. >> >> Which is still counterproductive for use cases other than small deep >> embedded systems. > > Okay, so that option is gone. > >> > > Besides, we are not looking to give up performance vs BASE_SMALL's >> > > "may reduce performance" help text. >> > > >> > > Yes, yes, it would simplify things to just get rid of non-preemptible RCU, >> > > but that is simply not in the cards at the moment. >> > >> > Not sure what the time frame is here. If we go for LAZY and remove NONE >> > and VOLUNTARY then making PREEMPT_RCU would make sense to lower the >> > memory footprint (and not attaching to BASE_SMALL). >> > >> > Is this what you intend or did misunderstand something here? >> >> My requirement is that LAZY not remove/disable/whatever non-preemptible >> RCU. Those currently using non-preemptible RCU should continue to be able >> to be able to use it, with or without LAZY. So why is this requirement >> a problem for you? Or am I missing your point? > > Those who were using non-preemptible RCU, whish to use LAZY_PREEPMT + > !PREEMPT_DYNAMIC should be able to disable PREEMPT_RCU only in this case. > Would the following work? > > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt > index 8cf8a9a4d868c..2183c775e7808 100644 > --- a/kernel/Kconfig.preempt > +++ b/kernel/Kconfig.preempt > @@ -121,6 +121,7 @@ config PREEMPT_COUNT > config PREEMPTION > bool > select PREEMPT_COUNT > + select PREEMPT_RCU if PREEMPT_DYNAMIC > > config PREEMPT_DYNAMIC > bool "Preemption behaviour defined on boot" > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > index 3e079de0f5b43..9e4bdbbca4ff9 100644 > --- a/kernel/rcu/Kconfig > +++ b/kernel/rcu/Kconfig > @@ -17,7 +17,7 @@ config TREE_RCU > smaller systems. > > config PREEMPT_RCU > - bool > + bool "Preemptible RCU" > default y if PREEMPTION > select TREE_RCU > help > @@ -91,7 +91,7 @@ config NEED_TASKS_RCU > > config TASKS_RCU > bool > - default NEED_TASKS_RCU && (PREEMPTION || PREEMPT_AUTO) > + default NEED_TASKS_RCU && PREEMPTION > select IRQ_WORK > > config FORCE_TASKS_RUDE_RCU > > I added TASKS_RCU to the hunk since I am not sure if you wish to follow > PREEMPTION (which is set by LAZY) or PREEMPT_RCU. > >> Thanx, Paul > > Sebastian -- ankur
On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: > Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > > >> > >> As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change > >> than just keeping non-preemptible RCU when the Kconfig options are > >> consistent with this being expected. If this is the case, what are the > >> benefits of this more-intrusive change? > > > > As far as I understand you are only concerned about PREEMPT_LAZY and > > everything else (PREEMPT_LAZY + PREEMPT_DYNAMIC or PREEMPT_DYNAMIC > > without PREEMPT_LAZY) is fine. > > In the PREEMPT_LAZY + !PREEMPT_DYNAMIC the suggested change > > > > | config PREEMPT_RCU > > | bool > > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > > | select TREE_RCU > > | help > > > > would disable PREEMPT_RCU while the default model is PREEMPT. You argue > > With PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n, isn't the default model > PREEMPT_LAZY, which has PREEMPTION=y, but PREEMPT=n? Correct. > > that only people on small embedded would do such a thing and they would > > like to safe additional memory. > > > > I don't think this is always the case because the "preemptible" users > > would also get this and this is an unexpected change for them. > > Can you clarify this? The intent with lazy is to be preemptible but > preempt less often. In that it is meant to be quite different from > CONFIG_PREEMPT. A wake up with PREEMPT may not always lead to a preemption but will lead to preemption once the time slice is up. With LAZY this changes to the point that a preemption point will be delayed to the sched tick. Tasks which are not based on the fail class (SCHED_DL, FIFO, …) will receive a wake up right away. If in the long term NONE and VOL goes away you could argue that everyone using LAZY + !DYNAMIC is one of those. If additionally PREEMPT goes away then you can not. Therefore I would prefer to have the RCU model to be selectable rather than forced. While !PREEMPT_RCU may save memory, it also disable preemption for the read section. > Ankur Sebastian
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: >> >> >> >> >> As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change >> >> than just keeping non-preemptible RCU when the Kconfig options are >> >> consistent with this being expected. If this is the case, what are the >> >> benefits of this more-intrusive change? >> > >> > As far as I understand you are only concerned about PREEMPT_LAZY and >> > everything else (PREEMPT_LAZY + PREEMPT_DYNAMIC or PREEMPT_DYNAMIC >> > without PREEMPT_LAZY) is fine. >> > In the PREEMPT_LAZY + !PREEMPT_DYNAMIC the suggested change >> > >> > | config PREEMPT_RCU >> > | bool >> > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) >> > | select TREE_RCU >> > | help >> > >> > would disable PREEMPT_RCU while the default model is PREEMPT. You argue >> >> With PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n, isn't the default model >> PREEMPT_LAZY, which has PREEMPTION=y, but PREEMPT=n? > > Correct. > >> > that only people on small embedded would do such a thing and they would >> > like to safe additional memory. >> > >> > I don't think this is always the case because the "preemptible" users >> > would also get this and this is an unexpected change for them. >> >> Can you clarify this? The intent with lazy is to be preemptible but >> preempt less often. In that it is meant to be quite different from >> CONFIG_PREEMPT. > > A wake up with PREEMPT may not always lead to a preemption but will lead > to preemption once the time slice is up. With LAZY this changes to the > point that a preemption point will be delayed to the sched tick. Tasks > which are not based on the fail class (SCHED_DL, FIFO, …) will receive a > wake up right away. >> > I don't think this is always the case because the "preemptible" users >> > would also get this and this is an unexpected change for them. Yes. My point was that "preemptible" is a mechanism. The policy about how often preemption happens is determined by the chosen model PREEMPT_NONE/PREEMPT_VOLUNTARY/PREEMPT_LAZY/PREEMPT/ PREEMPT_RT. > If in the long term NONE and VOL goes away you could argue that everyone > using LAZY + !DYNAMIC is one of those. > If additionally PREEMPT goes away then you can not. Sure. But, that's just begging the question. We want _NONE and _VOLUNTARY to go away because keeping cond_resched() around incurs a cost. > Therefore I would prefer to have the RCU model to be > selectable rather than forced. While !PREEMPT_RCU may save memory, it > also disable preemption for the read section. When a user chooses one of PREEMPT_NONE/_VOLUNTARY/_LAZY, the implication is that on the throughput -- latency axis, they care about optimizing for throughput. PREEMPT_RCU=n is clearly oriented towards that. That said, I'm agnostic about making the RCU model selectable. Paul is the best judge of that. -- ankur
On Thu, Oct 17, 2024 at 03:50:46PM -0700, Ankur Arora wrote: > Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: > >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > >> > >> >> > >> >> As for PREEMPT_LAZY, you seem to be suggesting a more intrusive change > >> >> than just keeping non-preemptible RCU when the Kconfig options are > >> >> consistent with this being expected. If this is the case, what are the > >> >> benefits of this more-intrusive change? > >> > > >> > As far as I understand you are only concerned about PREEMPT_LAZY and > >> > everything else (PREEMPT_LAZY + PREEMPT_DYNAMIC or PREEMPT_DYNAMIC > >> > without PREEMPT_LAZY) is fine. > >> > In the PREEMPT_LAZY + !PREEMPT_DYNAMIC the suggested change > >> > > >> > | config PREEMPT_RCU > >> > | bool > >> > | default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC) > >> > | select TREE_RCU > >> > | help > >> > > >> > would disable PREEMPT_RCU while the default model is PREEMPT. You argue > >> > >> With PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n, isn't the default model > >> PREEMPT_LAZY, which has PREEMPTION=y, but PREEMPT=n? > > > > Correct. > > > >> > that only people on small embedded would do such a thing and they would > >> > like to safe additional memory. > >> > > >> > I don't think this is always the case because the "preemptible" users > >> > would also get this and this is an unexpected change for them. > >> > >> Can you clarify this? The intent with lazy is to be preemptible but > >> preempt less often. In that it is meant to be quite different from > >> CONFIG_PREEMPT. > > > > A wake up with PREEMPT may not always lead to a preemption but will lead > > to preemption once the time slice is up. With LAZY this changes to the > > point that a preemption point will be delayed to the sched tick. Tasks > > which are not based on the fail class (SCHED_DL, FIFO, …) will receive a > > wake up right away. > > >> > I don't think this is always the case because the "preemptible" users > >> > would also get this and this is an unexpected change for them. > > Yes. My point was that "preemptible" is a mechanism. > > The policy about how often preemption happens is determined by the > chosen model PREEMPT_NONE/PREEMPT_VOLUNTARY/PREEMPT_LAZY/PREEMPT/ > PREEMPT_RT. > > > If in the long term NONE and VOL goes away you could argue that everyone > > using LAZY + !DYNAMIC is one of those. > > > If additionally PREEMPT goes away then you can not. > > Sure. But, that's just begging the question. > > We want _NONE and _VOLUNTARY to go away because keeping cond_resched() > around incurs a cost. When you say "go away", do you mean for your use cases? Or globally? > > Therefore I would prefer to have the RCU model to be > > selectable rather than forced. While !PREEMPT_RCU may save memory, it > > also disable preemption for the read section. > > When a user chooses one of PREEMPT_NONE/_VOLUNTARY/_LAZY, the implication > is that on the throughput -- latency axis, they care about optimizing > for throughput. > > PREEMPT_RCU=n is clearly oriented towards that. Agreed! > That said, I'm agnostic about making the RCU model selectable. Paul > is the best judge of that. I am not seeing any reason to make it once again be selectable, and plenty of reasons to keep it automatic. If I am missing some motivation to bother users with the need to make this decision, please let me know what that motivation might be. Thanx, Paul
Paul E. McKenney <paulmck@kernel.org> writes: > On Thu, Oct 17, 2024 at 03:50:46PM -0700, Ankur Arora wrote: >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: >> > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: >> >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: >> >> [ ... ] >> Sure. But, that's just begging the question. >> >> We want _NONE and _VOLUNTARY to go away because keeping cond_resched() >> around incurs a cost. > > When you say "go away", do you mean for your use cases? Or globally? When I say "want _ to go away" I mean: cond_resched() is deleterious to performance since you are forced to have code which can do the rescheduling check synchronously -- when this could easily be done asynchronously (as the non voluntary models do). And this either means poor performance (ex. in the page zeroing code where it would be more optimal to work on continguous ranges) or gyrations like the ones that xen_pv_evtchn_do_upcall() and the Xen hypervisor have to go through. And, as we've discussed before, the cond_resched() interface, while it works, is not ideal. Also, a man can dream! -- ankur
On Fri, Oct 18, 2024 at 12:18:04PM -0700, Ankur Arora wrote: > > Paul E. McKenney <paulmck@kernel.org> writes: > > > On Thu, Oct 17, 2024 at 03:50:46PM -0700, Ankur Arora wrote: > >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > >> > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: > >> >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > >> >> > [ ... ] > >> Sure. But, that's just begging the question. > >> > >> We want _NONE and _VOLUNTARY to go away because keeping cond_resched() > >> around incurs a cost. > > > > When you say "go away", do you mean for your use cases? Or globally? > > When I say "want _ to go away" I mean: cond_resched() is deleterious > to performance since you are forced to have code which can do the > rescheduling check synchronously -- when this could easily be done > asynchronously (as the non voluntary models do). > > And this either means poor performance (ex. in the page zeroing code > where it would be more optimal to work on continguous ranges) or > gyrations like the ones that xen_pv_evtchn_do_upcall() and the > Xen hypervisor have to go through. > > And, as we've discussed before, the cond_resched() interface, while it > works, is not ideal. I would expect that many instances of cond_resched() could go away given lazy preemption, but I would not be surprised if there were some that needed to stay around. Your thought being that if *all* instance of cond_resched() go away, then PREEMPT_NONE also goes away? Given how long PREEMPT_NONE has been around, this would need to be done (and communicated) quite carefully. > Also, a man can dream! Fair enough, just be very careful to distinguish dreams from reality. ;-) Thanx, Paul
Paul E. McKenney <paulmck@kernel.org> writes: > On Fri, Oct 18, 2024 at 12:18:04PM -0700, Ankur Arora wrote: >> >> Paul E. McKenney <paulmck@kernel.org> writes: >> >> > On Thu, Oct 17, 2024 at 03:50:46PM -0700, Ankur Arora wrote: >> >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: >> >> > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: >> >> >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: >> >> >> >> [ ... ] >> >> Sure. But, that's just begging the question. >> >> >> >> We want _NONE and _VOLUNTARY to go away because keeping cond_resched() >> >> around incurs a cost. >> > >> > When you say "go away", do you mean for your use cases? Or globally? >> >> When I say "want _ to go away" I mean: cond_resched() is deleterious >> to performance since you are forced to have code which can do the >> rescheduling check synchronously -- when this could easily be done >> asynchronously (as the non voluntary models do). >> >> And this either means poor performance (ex. in the page zeroing code >> where it would be more optimal to work on continguous ranges) or >> gyrations like the ones that xen_pv_evtchn_do_upcall() and the >> Xen hypervisor have to go through. >> >> And, as we've discussed before, the cond_resched() interface, while it >> works, is not ideal. > > I would expect that many instances of cond_resched() could go away given > lazy preemption, but I would not be surprised if there were some that > needed to stay around. > > Your thought being that if *all* instance of cond_resched() go away, > then PREEMPT_NONE also goes away? If *all* instances of cond_resched() go away, is there anything left of PREEMPT_NONE? > Given how long PREEMPT_NONE has been > around, this would need to be done (and communicated) quite carefully. I don't think there's any question about that. >> Also, a man can dream! > > Fair enough, just be very careful to distinguish dreams from reality. ;-) I've generally not found that to be a problem, but thanks for the warning. -- ankur
On Fri, Oct 18, 2024 at 06:07:52PM -0700, Ankur Arora wrote: > > Paul E. McKenney <paulmck@kernel.org> writes: > > > On Fri, Oct 18, 2024 at 12:18:04PM -0700, Ankur Arora wrote: > >> > >> Paul E. McKenney <paulmck@kernel.org> writes: > >> > >> > On Thu, Oct 17, 2024 at 03:50:46PM -0700, Ankur Arora wrote: > >> >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > >> >> > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote: > >> >> >> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > >> >> >> > >> [ ... ] > >> >> Sure. But, that's just begging the question. > >> >> > >> >> We want _NONE and _VOLUNTARY to go away because keeping cond_resched() > >> >> around incurs a cost. > >> > > >> > When you say "go away", do you mean for your use cases? Or globally? > >> > >> When I say "want _ to go away" I mean: cond_resched() is deleterious > >> to performance since you are forced to have code which can do the > >> rescheduling check synchronously -- when this could easily be done > >> asynchronously (as the non voluntary models do). > >> > >> And this either means poor performance (ex. in the page zeroing code > >> where it would be more optimal to work on continguous ranges) or > >> gyrations like the ones that xen_pv_evtchn_do_upcall() and the > >> Xen hypervisor have to go through. > >> > >> And, as we've discussed before, the cond_resched() interface, while it > >> works, is not ideal. > > > > I would expect that many instances of cond_resched() could go away given > > lazy preemption, but I would not be surprised if there were some that > > needed to stay around. > > > > Your thought being that if *all* instance of cond_resched() go away, > > then PREEMPT_NONE also goes away? > > If *all* instances of cond_resched() go away, is there anything left of > PREEMPT_NONE? Yes, namely its relationship to PREEMPT_RCU. Which, yes, can be adjusted, perhaps even as Sebastian suggested. But such an adjustment cannot be applied suddenly without warning. > > Given how long PREEMPT_NONE has been > > around, this would need to be done (and communicated) quite carefully. > > I don't think there's any question about that. Whew!!! > >> Also, a man can dream! > > > > Fair enough, just be very careful to distinguish dreams from reality. ;-) > > I've generally not found that to be a problem, but thanks for the warning. "It is a service that I provide." ;-) Thanx, Paul
On Wed, Oct 09, 2024 at 11:24:09AM -0700, Paul E. McKenney wrote: > On Wed, Oct 09, 2024 at 08:01:17PM +0200, Peter Zijlstra wrote: > > On Wed, Oct 09, 2024 at 09:54:06AM -0700, Ankur Arora wrote: > > > PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC > > > which allows for dynamic switching of preemption models. > > > > > > The choice of preemptible RCU or not, however, is fixed at compile > > > time. Given the trade-offs made to have a preemptible RCU, some > > > configurations which have limited preemption might prefer the > > > stronger forward-progress guarantees of PREEMPT_RCU=n. > > > > > > Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC, > > > PREEMPT, PREEMPT_RT. > > > > > > This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects > > > PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y, > > > PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y. > > > > I am completely confused by this. Why do we want this? > > In order to support systems that currently run CONFIG_PREEMPT=n that > are adequately but not overly endowed with memory. If we allow all > RCU readers to be preempted, we increase grace-period latency, and also > increase OOM incidence. Which we would like to avoid. > > But we do want lazy preemption otherwise, for but one thing to reduce > tail latencies and to reduce the need for preemption points. Thus, we > want a way to allow lazy preemption in general, but to continue with > non-preemptible RCU read-side critical sections. > > Or am I once again missing your point? Even without this patch this is allowed, right? It's just a default that's changed. If people want to run PREEMPT_RCU=n, they can select it. I just don't see a point in making this change.
On Wed, Oct 09, 2024 at 10:52:18PM +0200, Peter Zijlstra wrote: > On Wed, Oct 09, 2024 at 11:24:09AM -0700, Paul E. McKenney wrote: > > On Wed, Oct 09, 2024 at 08:01:17PM +0200, Peter Zijlstra wrote: > > > On Wed, Oct 09, 2024 at 09:54:06AM -0700, Ankur Arora wrote: > > > > PREEMPT_LAZY can be enabled stand-alone or alongside PREEMPT_DYNAMIC > > > > which allows for dynamic switching of preemption models. > > > > > > > > The choice of preemptible RCU or not, however, is fixed at compile > > > > time. Given the trade-offs made to have a preemptible RCU, some > > > > configurations which have limited preemption might prefer the > > > > stronger forward-progress guarantees of PREEMPT_RCU=n. > > > > > > > > Accordingly, explicitly limit PREEMPT_RCU=y to PREEMPT_DYNAMIC, > > > > PREEMPT, PREEMPT_RT. > > > > > > > > This means that (PREEMPT_LAZY=y, PREEMPT_DYNAMIC=n), which selects > > > > PREEMPTION will run with PREEMPT_RCU=n. The combination (PREEMPT_LAZY=y, > > > > PREEMPT_DYNAMIC=y), will run with PREEMPT_RCU=y. > > > > > > I am completely confused by this. Why do we want this? > > > > In order to support systems that currently run CONFIG_PREEMPT=n that > > are adequately but not overly endowed with memory. If we allow all > > RCU readers to be preempted, we increase grace-period latency, and also > > increase OOM incidence. Which we would like to avoid. > > > > But we do want lazy preemption otherwise, for but one thing to reduce > > tail latencies and to reduce the need for preemption points. Thus, we > > want a way to allow lazy preemption in general, but to continue with > > non-preemptible RCU read-side critical sections. > > > > Or am I once again missing your point? > > Even without this patch this is allowed, right? It's just a default > that's changed. If people want to run PREEMPT_RCU=n, they can select it. > > I just don't see a point in making this change. Because we don't need a bunch of people surprised by this change in behavior. Thanx, Paul
On Wed, Oct 09, 2024 at 02:16:43PM -0700, Paul E. McKenney wrote: > Because we don't need a bunch of people surprised by this change in > behavior. I'm not sure what change in behaviour; Lazy is brand spanking new, it will have new behaviour not in line with previous modes. Just put in the help text that if you're looking for a reality closer to the old Voluntary to use PREEMPT_RCU=n. In reality very few people will care, because distros will be running PREEMPT_DYNAMIC and the 3 people doing their own thing ought to be savvy enough to deal with things, no?
On Thu, Oct 10, 2024 at 09:58:50AM +0200, Peter Zijlstra wrote: > On Wed, Oct 09, 2024 at 02:16:43PM -0700, Paul E. McKenney wrote: > > > Because we don't need a bunch of people surprised by this change in > > behavior. > > I'm not sure what change in behaviour; Lazy is brand spanking new, it > will have new behaviour not in line with previous modes. Just put in the > help text that if you're looking for a reality closer to the old > Voluntary to use PREEMPT_RCU=n. > > In reality very few people will care, because distros will be running > PREEMPT_DYNAMIC and the 3 people doing their own thing ought to be savvy > enough to deal with things, no? No. Sure, a number of them have proven themselves capable of debugging back from an otherwise inexplicable series of OOMs not obviously caused by RCU Kconfig settings, but why put them through that? And especially, why put others through such a "learning experience"? Why not instead tag the Kconfig help text noting that lazy preemption does not automatically apply to RCU read-side critical sections, and that if you want it to, there is a Kconfig option that is there for you? Thanx, Paul
© 2016 - 2024 Red Hat, Inc.