From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ankur Arora <ankur.a.arora@oracle.com>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@kernel.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, frederic@kernel.org, efault@gmx.de
Subject: Re: [PATCH 2/7] rcu: limit PREEMPT_RCU configurations
Date: Tue, 15 Oct 2024 13:22:24 +0200 [thread overview]
Message-ID: <20241015112224.KdvzKo80@linutronix.de> (raw)
In-Reply-To: <dcffa722-986a-437b-abb9-af9f4de852df@paulmck-laptop>
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
next prev parent reply other threads:[~2024-10-15 11:22 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 16:54 [PATCH 0/7] Lazy preemption bits Ankur Arora
2024-10-09 16:54 ` [PATCH 1/7] sched: warn for high latency with TIF_NEED_RESCHED_LAZY Ankur Arora
2024-10-10 6:37 ` Sebastian Andrzej Siewior
2024-10-10 18:19 ` Ankur Arora
2024-10-13 9:44 ` kernel test robot
2024-10-13 9:54 ` kernel test robot
2024-10-16 9:36 ` Shrikanth Hegde
2024-10-21 19:21 ` Ankur Arora
2024-10-22 5:41 ` Shrikanth Hegde
2024-10-09 16:54 ` [PATCH 2/7] rcu: limit PREEMPT_RCU configurations Ankur Arora
2024-10-09 18:01 ` Peter Zijlstra
2024-10-09 18:24 ` Paul E. McKenney
2024-10-09 20:52 ` Peter Zijlstra
2024-10-09 21:16 ` Paul E. McKenney
2024-10-10 7:58 ` Peter Zijlstra
2024-10-10 14:19 ` Paul E. McKenney
2024-10-10 6:32 ` Sebastian Andrzej Siewior
2024-10-10 8:10 ` Peter Zijlstra
2024-10-10 9:13 ` Sebastian Andrzej Siewior
2024-10-10 10:03 ` Peter Zijlstra
2024-10-10 10:26 ` Sebastian Andrzej Siewior
2024-10-10 10:44 ` Peter Zijlstra
2024-10-10 14:29 ` Paul E. McKenney
2024-10-11 8:18 ` Sebastian Andrzej Siewior
2024-10-11 13:59 ` Paul E. McKenney
2024-10-11 14:43 ` Sebastian Andrzej Siewior
2024-10-11 15:59 ` Paul E. McKenney
2024-10-15 11:22 ` Sebastian Andrzej Siewior [this message]
2024-10-15 22:13 ` Ankur Arora
2024-10-17 8:04 ` Sebastian Andrzej Siewior
2024-10-17 22:50 ` Ankur Arora
2024-10-18 17:43 ` Paul E. McKenney
2024-10-18 19:18 ` Ankur Arora
2024-10-18 23:24 ` Paul E. McKenney
2024-10-19 1:07 ` Ankur Arora
2024-10-19 4:30 ` Paul E. McKenney
2024-10-15 23:11 ` Paul E. McKenney
2024-10-17 7:07 ` Sebastian Andrzej Siewior
2024-10-18 17:38 ` Paul E. McKenney
2024-10-21 11:27 ` Sebastian Andrzej Siewior
2024-10-21 16:48 ` Paul E. McKenney
2024-10-21 19:20 ` Ankur Arora
2024-10-22 23:49 ` Paul E. McKenney
2024-10-22 14:09 ` Sebastian Andrzej Siewior
2024-10-22 23:54 ` Paul E. McKenney
2024-10-23 6:58 ` Sebastian Andrzej Siewior
2024-10-10 17:35 ` Ankur Arora
2024-10-11 7:58 ` Sebastian Andrzej Siewior
2024-10-15 23:01 ` Ankur Arora
2024-10-10 17:42 ` Ankur Arora
2024-10-09 16:54 ` [PATCH 3/7] rcu: fix header guard for rcu_all_qs() Ankur Arora
2024-10-10 6:41 ` Sebastian Andrzej Siewior
2024-10-10 8:11 ` Peter Zijlstra
2024-10-10 14:29 ` Paul E. McKenney
2024-10-09 16:54 ` [PATCH 4/7] rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y Ankur Arora
2024-10-09 19:05 ` Ankur Arora
2024-10-10 14:37 ` Paul E. McKenney
2024-10-10 17:59 ` Ankur Arora
2024-10-10 6:50 ` Sebastian Andrzej Siewior
2024-10-10 17:56 ` Ankur Arora
2024-10-11 7:52 ` Sebastian Andrzej Siewior
2024-10-09 16:54 ` [PATCH 5/7] rcu: rename PREEMPT_AUTO to PREEMPT_LAZY Ankur Arora
2024-10-09 18:02 ` Peter Zijlstra
2024-10-09 18:52 ` Ankur Arora
2024-10-09 16:54 ` [PATCH 6/7] osnoise: handle quiescent states for PREEMPT_RCU=n, PREEMPTION=y Ankur Arora
2024-10-10 6:53 ` Sebastian Andrzej Siewior
2024-10-10 14:39 ` Paul E. McKenney
2024-10-10 17:50 ` Ankur Arora
2024-10-11 7:36 ` Sebastian Andrzej Siewior
2024-10-14 20:14 ` Ankur Arora
2024-10-09 16:54 ` [PATCH 7/7] powerpc: add support for PREEMPT_LAZY Ankur Arora
2024-10-10 7:22 ` Sebastian Andrzej Siewior
2024-10-10 18:10 ` Ankur Arora
2024-10-11 18:35 ` Shrikanth Hegde
2024-10-12 22:42 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241015112224.KdvzKo80@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=ankur.a.arora@oracle.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=efault@gmx.de \
--cc=frederic@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®