The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
works at cross purposes: the RCU read side critical sections disable
preemption, while preempt=full schedules eagerly to minimize
latency.
Warn if the user is switching to full preemption with PREEMPT_RCU=n.
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
kernel/sched/core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d7804e29182d..df8e333f2d8b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
break;
case preempt_dynamic_full:
+ if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
+ pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
+ PREEMPT_MODE);
+
preempt_dynamic_mode = preempt_dynamic_undefined;
break;
}
--
2.31.1On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
> The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
> works at cross purposes: the RCU read side critical sections disable
> preemption, while preempt=full schedules eagerly to minimize
> latency.
>
> Warn if the user is switching to full preemption with PREEMPT_RCU=n.
>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> ---
> kernel/sched/core.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d7804e29182d..df8e333f2d8b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
> break;
>
> case preempt_dynamic_full:
> + if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
> + pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
> + PREEMPT_MODE);
> +
Yeah, so I don't believe this is a viable strategy.
Firstly, none of these RCU patches are actually about the whole LAZY
preempt scheme, they apply equally well (arguably better) to the
existing PREEMPT_DYNAMIC thing.
Secondly, esp. with the LAZY thing, you are effectively running FULL at
all times. It's just that some of the preemptions, typically those of
the normal scheduling class are somewhat delayed. However RT/DL classes
are still insta preempt.
Meaning that if you run anything in the realtime classes you're running
a fully preemptible kernel. As such, RCU had better be able to deal with
it.
So no, I don't believe this is right.
Peter Zijlstra <peterz@infradead.org> writes:
> On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
>> The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
>> works at cross purposes: the RCU read side critical sections disable
>> preemption, while preempt=full schedules eagerly to minimize
>> latency.
>>
>> Warn if the user is switching to full preemption with PREEMPT_RCU=n.
>>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Juri Lelli <juri.lelli@redhat.com>
>> Cc: Vincent Guittot <vincent.guittot@linaro.org>
>> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
>> Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> ---
>> kernel/sched/core.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index d7804e29182d..df8e333f2d8b 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
>> break;
>>
>> case preempt_dynamic_full:
>> + if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
>> + pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
>> + PREEMPT_MODE);
>> +
>
> Yeah, so I don't believe this is a viable strategy.
>
> Firstly, none of these RCU patches are actually about the whole LAZY
> preempt scheme, they apply equally well (arguably better) to the
> existing PREEMPT_DYNAMIC thing.
Agreed.
> Secondly, esp. with the LAZY thing, you are effectively running FULL at
> all times. It's just that some of the preemptions, typically those of
> the normal scheduling class are somewhat delayed. However RT/DL classes
> are still insta preempt.
Also, agreed.
> Meaning that if you run anything in the realtime classes you're running
> a fully preemptible kernel. As such, RCU had better be able to deal with
> it.
So, RCU can deal with (PREEMPT_RCU=y, PREEMPT_AUTO=y, preempt=none/voluntary/full).
Since that's basically what PREEMPT_DYNAMIC already works with.
The other combination, (PREEMPT_RCU=n, PREEMPT_AUTO,
preempt=none/voluntary) would generally be business as usual, except, as
you say, it is really PREEMPT_RCU=n, preempt=full in disguise.
However, as Paul says __rcu_read_lock(), for PREEMPT_RCU=n is defined as:
static inline void __rcu_read_lock(void)
{
preempt_disable();
}
So, this combination -- though non standard -- should also work.
The reason for adding the warning was because Paul had warned in
discussions earlier (see here for instance:
https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/)
that the PREEMPT_FULL=y and PREEMPT_RCU=n is basically useless. But at
least in my understanding that's primarily a performance concern not a
correctness concern. But, Paul can probably speak to that more.
"PREEMPT_FULL=y plus PREEMPT_RCU=n appears to be a useless
combination. All of the gains from PREEMPT_FULL=y are more than lost
due to PREEMPT_RCU=n, especially when the kernel decides to do something
like walk a long task list under RCU protection. We should not waste
people's time getting burned by this combination, nor should we waste
cycles testing it."
--
ankur
On Thu, May 30, 2024 at 04:04:41PM -0700, Ankur Arora wrote:
>
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
> >> The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
> >> works at cross purposes: the RCU read side critical sections disable
> >> preemption, while preempt=full schedules eagerly to minimize
> >> latency.
> >>
> >> Warn if the user is switching to full preemption with PREEMPT_RCU=n.
> >>
> >> Cc: Ingo Molnar <mingo@redhat.com>
> >> Cc: Peter Zijlstra <peterz@infradead.org>
> >> Cc: Juri Lelli <juri.lelli@redhat.com>
> >> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> >> Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> >> Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
> >> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> >> ---
> >> kernel/sched/core.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index d7804e29182d..df8e333f2d8b 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
> >> break;
> >>
> >> case preempt_dynamic_full:
> >> + if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
> >> + pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
> >> + PREEMPT_MODE);
> >> +
> >
> > Yeah, so I don't believe this is a viable strategy.
> >
> > Firstly, none of these RCU patches are actually about the whole LAZY
> > preempt scheme, they apply equally well (arguably better) to the
> > existing PREEMPT_DYNAMIC thing.
>
> Agreed.
>
> > Secondly, esp. with the LAZY thing, you are effectively running FULL at
> > all times. It's just that some of the preemptions, typically those of
> > the normal scheduling class are somewhat delayed. However RT/DL classes
> > are still insta preempt.
>
> Also, agreed.
>
> > Meaning that if you run anything in the realtime classes you're running
> > a fully preemptible kernel. As such, RCU had better be able to deal with
> > it.
>
> So, RCU can deal with (PREEMPT_RCU=y, PREEMPT_AUTO=y, preempt=none/voluntary/full).
> Since that's basically what PREEMPT_DYNAMIC already works with.
>
> The other combination, (PREEMPT_RCU=n, PREEMPT_AUTO,
> preempt=none/voluntary) would generally be business as usual, except, as
> you say, it is really PREEMPT_RCU=n, preempt=full in disguise.
>
> However, as Paul says __rcu_read_lock(), for PREEMPT_RCU=n is defined as:
>
> static inline void __rcu_read_lock(void)
> {
> preempt_disable();
> }
>
> So, this combination -- though non standard -- should also work.
>
> The reason for adding the warning was because Paul had warned in
> discussions earlier (see here for instance:
> https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/)
>
> that the PREEMPT_FULL=y and PREEMPT_RCU=n is basically useless. But at
> least in my understanding that's primarily a performance concern not a
> correctness concern. But, Paul can probably speak to that more.
>
> "PREEMPT_FULL=y plus PREEMPT_RCU=n appears to be a useless
> combination. All of the gains from PREEMPT_FULL=y are more than lost
> due to PREEMPT_RCU=n, especially when the kernel decides to do something
> like walk a long task list under RCU protection. We should not waste
> people's time getting burned by this combination, nor should we waste
> cycles testing it."
My selfish motivation here is to avoid testing this combination unless
and until someone actually has a good use for it. I do not think that
anyone will ever need it, but perhaps I am suffering from a failure
of imagination. If so, they hit that WARN, complain and explain their
use case, and at that point I start testing it (and fixing whatever bugs
have accumulated in the meantime). But until that time, I save time by
avoiding testing it.
Thanx, Paul
On Thu, May 30, 2024 at 04:20:26PM -0700, Paul E. McKenney wrote: > My selfish motivation here is to avoid testing this combination unless > and until someone actually has a good use for it. That doesn't make sense, the whole LAZY thing is fundamentally identical to FULL, except it sometimes delays the preemption a wee bit. But all the preemption scenarios from FULL are possible. As such, it makes far more sense to only test FULL.
On Thu, Jun 06, 2024 at 01:53:25PM +0200, Peter Zijlstra wrote: > On Thu, May 30, 2024 at 04:20:26PM -0700, Paul E. McKenney wrote: > > > My selfish motivation here is to avoid testing this combination unless > > and until someone actually has a good use for it. > > That doesn't make sense, the whole LAZY thing is fundamentally identical > to FULL, except it sometimes delays the preemption a wee bit. But all > the preemption scenarios from FULL are possible. As noted earlier in this thread, this is not the case for non-preemptible RCU, which disables preemption across its read-side critical sections. In addition, from a performance/throughput viewpoint, it is not just the possibility of preemption that matters, but also the probability. > As such, it makes far more sense to only test FULL. You have considerable work left to do in order to convince me of this one. Thanx, Paul
On Thu, Jun 06, 2024 at 06:38:57AM -0700, Paul E. McKenney wrote: > On Thu, Jun 06, 2024 at 01:53:25PM +0200, Peter Zijlstra wrote: > > On Thu, May 30, 2024 at 04:20:26PM -0700, Paul E. McKenney wrote: > > > > > My selfish motivation here is to avoid testing this combination unless > > > and until someone actually has a good use for it. > > > > That doesn't make sense, the whole LAZY thing is fundamentally identical > > to FULL, except it sometimes delays the preemption a wee bit. But all > > the preemption scenarios from FULL are possible. > > As noted earlier in this thread, this is not the case for non-preemptible > RCU, which disables preemption across its read-side critical sections. > In addition, from a performance/throughput viewpoint, it is not just > the possibility of preemption that matters, but also the probability. > > > As such, it makes far more sense to only test FULL. > > You have considerable work left to do in order to convince me of this one. On the other hand, it does make sense to select Tiny SRCU for all !SMP kernels, whether preemptible or not. And it also makes sense to test (but not *only* test and definitely *not* support) non-preemptible RCU running in a preemptible kernel, perhaps as a one-off, perhaps longer term. The point being of course that the increased preemption rate of a fully preemptible kernel should uncover bugs that might appear in lazy-preemptible kernels only very rarely. This might have been what you were getting at, and if so, apologies! But in my defense, you did say "only test FULL" above. ;-) Thanx, Paul
On Mon, Jun 17, 2024 at 08:54:49AM -0700, Paul E. McKenney wrote: > On Thu, Jun 06, 2024 at 06:38:57AM -0700, Paul E. McKenney wrote: > > On Thu, Jun 06, 2024 at 01:53:25PM +0200, Peter Zijlstra wrote: > > > On Thu, May 30, 2024 at 04:20:26PM -0700, Paul E. McKenney wrote: > > > > > > > My selfish motivation here is to avoid testing this combination unless > > > > and until someone actually has a good use for it. > > > > > > That doesn't make sense, the whole LAZY thing is fundamentally identical > > > to FULL, except it sometimes delays the preemption a wee bit. But all > > > the preemption scenarios from FULL are possible. > > > > As noted earlier in this thread, this is not the case for non-preemptible > > RCU, which disables preemption across its read-side critical sections. > > In addition, from a performance/throughput viewpoint, it is not just > > the possibility of preemption that matters, but also the probability. > > > > > As such, it makes far more sense to only test FULL. > > > > You have considerable work left to do in order to convince me of this one. > > On the other hand, it does make sense to select Tiny SRCU for all !SMP > kernels, whether preemptible or not. Except that testing made a liar out of me. SRCU priority boosting would be required. So this one is also strictly for pre-testing lazy preemption. As usual, it seemed like a good idea at the time... ;-) Thanx, Paul > And it also makes sense to test > (but not *only* test and definitely *not* support) non-preemptible > RCU running in a preemptible kernel, perhaps as a one-off, perhaps > longer term. The point being of course that the increased preemption > rate of a fully preemptible kernel should uncover bugs that might appear > in lazy-preemptible kernels only very rarely. > > This might have been what you were getting at, and if so, apologies! > But in my defense, you did say "only test FULL" above. ;-) > > Thanx, Paul
On Wed, May 29, 2024 at 10:14:04AM +0200, Peter Zijlstra wrote:
> On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
> > The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
> > works at cross purposes: the RCU read side critical sections disable
> > preemption, while preempt=full schedules eagerly to minimize
> > latency.
> >
> > Warn if the user is switching to full preemption with PREEMPT_RCU=n.
> >
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Juri Lelli <juri.lelli@redhat.com>
> > Cc: Vincent Guittot <vincent.guittot@linaro.org>
> > Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> > Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> > ---
> > kernel/sched/core.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index d7804e29182d..df8e333f2d8b 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
> > break;
> >
> > case preempt_dynamic_full:
> > + if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
> > + pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
> > + PREEMPT_MODE);
> > +
>
> Yeah, so I don't believe this is a viable strategy.
>
> Firstly, none of these RCU patches are actually about the whole LAZY
> preempt scheme, they apply equally well (arguably better) to the
> existing PREEMPT_DYNAMIC thing.
>
> Secondly, esp. with the LAZY thing, you are effectively running FULL at
> all times. It's just that some of the preemptions, typically those of
> the normal scheduling class are somewhat delayed. However RT/DL classes
> are still insta preempt.
>
> Meaning that if you run anything in the realtime classes you're running
> a fully preemptible kernel. As such, RCU had better be able to deal with
> it.
>
> So no, I don't believe this is right.
At one point, lazy preemption selected PREEMPT_COUNT (which I am
not seeing in this version, perhaps due to blindness on my part).
Of course, selecting PREEMPT_COUNT would result in !PREEMPT_RCU kernel's
rcu_read_lock() explicitly disabling preemption, thus avoiding preemption
(including lazy preemption) in RCU read-side critical sections.
Ankur, what am I missing here?
Thanx, Paul
Paul E. McKenney <paulmck@kernel.org> writes:
> On Wed, May 29, 2024 at 10:14:04AM +0200, Peter Zijlstra wrote:
>> On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
>> > The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
>> > works at cross purposes: the RCU read side critical sections disable
>> > preemption, while preempt=full schedules eagerly to minimize
>> > latency.
>> >
>> > Warn if the user is switching to full preemption with PREEMPT_RCU=n.
>> >
>> > Cc: Ingo Molnar <mingo@redhat.com>
>> > Cc: Peter Zijlstra <peterz@infradead.org>
>> > Cc: Juri Lelli <juri.lelli@redhat.com>
>> > Cc: Vincent Guittot <vincent.guittot@linaro.org>
>> > Suggested-by: Paul E. McKenney <paulmck@kernel.org>
>> > Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
>> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> > ---
>> > kernel/sched/core.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index d7804e29182d..df8e333f2d8b 100644
>> > --- a/kernel/sched/core.c
>> > +++ b/kernel/sched/core.c
>> > @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
>> > break;
>> >
>> > case preempt_dynamic_full:
>> > + if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
>> > + pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
>> > + PREEMPT_MODE);
>> > +
>>
>> Yeah, so I don't believe this is a viable strategy.
>>
>> Firstly, none of these RCU patches are actually about the whole LAZY
>> preempt scheme, they apply equally well (arguably better) to the
>> existing PREEMPT_DYNAMIC thing.
>>
>> Secondly, esp. with the LAZY thing, you are effectively running FULL at
>> all times. It's just that some of the preemptions, typically those of
>> the normal scheduling class are somewhat delayed. However RT/DL classes
>> are still insta preempt.
>>
>> Meaning that if you run anything in the realtime classes you're running
>> a fully preemptible kernel. As such, RCU had better be able to deal with
>> it.
>>
>> So no, I don't believe this is right.
>
> At one point, lazy preemption selected PREEMPT_COUNT (which I am
> not seeing in this version, perhaps due to blindness on my part).
> Of course, selecting PREEMPT_COUNT would result in !PREEMPT_RCU kernel's
> rcu_read_lock() explicitly disabling preemption, thus avoiding preemption
> (including lazy preemption) in RCU read-side critical sections.
That should be still happening, just transitively. PREEMPT_AUTO selects
PREEMPT_BUILD, which selects PREEMPTION, and that in turn selects
PREEMPT_COUNT.
--
ankur
On Thu, May 30, 2024 at 04:05:26PM -0700, Ankur Arora wrote:
>
> Paul E. McKenney <paulmck@kernel.org> writes:
>
> > On Wed, May 29, 2024 at 10:14:04AM +0200, Peter Zijlstra wrote:
> >> On Mon, May 27, 2024 at 05:35:02PM -0700, Ankur Arora wrote:
> >> > The combination of PREEMPT_RCU=n and (PREEMPT_AUTO=y, preempt=full)
> >> > works at cross purposes: the RCU read side critical sections disable
> >> > preemption, while preempt=full schedules eagerly to minimize
> >> > latency.
> >> >
> >> > Warn if the user is switching to full preemption with PREEMPT_RCU=n.
> >> >
> >> > Cc: Ingo Molnar <mingo@redhat.com>
> >> > Cc: Peter Zijlstra <peterz@infradead.org>
> >> > Cc: Juri Lelli <juri.lelli@redhat.com>
> >> > Cc: Vincent Guittot <vincent.guittot@linaro.org>
> >> > Suggested-by: Paul E. McKenney <paulmck@kernel.org>
> >> > Link: https://lore.kernel.org/lkml/842f589e-5ea3-4c2b-9376-d718c14fabf5@paulmck-laptop/
> >> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
> >> > ---
> >> > kernel/sched/core.c | 4 ++++
> >> > 1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> > index d7804e29182d..df8e333f2d8b 100644
> >> > --- a/kernel/sched/core.c
> >> > +++ b/kernel/sched/core.c
> >> > @@ -8943,6 +8943,10 @@ static void __sched_dynamic_update(int mode)
> >> > break;
> >> >
> >> > case preempt_dynamic_full:
> >> > + if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
> >> > + pr_warn("%s: preempt=full is not recommended with CONFIG_PREEMPT_RCU=n",
> >> > + PREEMPT_MODE);
> >> > +
> >>
> >> Yeah, so I don't believe this is a viable strategy.
> >>
> >> Firstly, none of these RCU patches are actually about the whole LAZY
> >> preempt scheme, they apply equally well (arguably better) to the
> >> existing PREEMPT_DYNAMIC thing.
> >>
> >> Secondly, esp. with the LAZY thing, you are effectively running FULL at
> >> all times. It's just that some of the preemptions, typically those of
> >> the normal scheduling class are somewhat delayed. However RT/DL classes
> >> are still insta preempt.
> >>
> >> Meaning that if you run anything in the realtime classes you're running
> >> a fully preemptible kernel. As such, RCU had better be able to deal with
> >> it.
> >>
> >> So no, I don't believe this is right.
> >
> > At one point, lazy preemption selected PREEMPT_COUNT (which I am
> > not seeing in this version, perhaps due to blindness on my part).
> > Of course, selecting PREEMPT_COUNT would result in !PREEMPT_RCU kernel's
> > rcu_read_lock() explicitly disabling preemption, thus avoiding preemption
> > (including lazy preemption) in RCU read-side critical sections.
>
> That should be still happening, just transitively. PREEMPT_AUTO selects
> PREEMPT_BUILD, which selects PREEMPTION, and that in turn selects
> PREEMPT_COUNT.
Ah, I gave up too soon. Thank you!
Thanx, Paul
© 2016 - 2026 Red Hat, Inc.