public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Mon, 21 Oct 2024 13:27:55 +0200	[thread overview]
Message-ID: <20241021112755.m7dWNbc0@linutronix.de> (raw)
In-Reply-To: <0313c8c5-a6a0-4d09-9f85-ac5afa379041@paulmck-laptop>

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

  reply	other threads:[~2024-10-21 11:27 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
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 [this message]
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=20241021112755.m7dWNbc0@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