public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ankur Arora <ankur.a.arora@oracle.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	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 15:13:46 -0700	[thread overview]
Message-ID: <87ed4hrp45.fsf@oracle.com> (raw)
In-Reply-To: <20241015112224.KdvzKo80@linutronix.de>


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

  reply	other threads:[~2024-10-15 22:14 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 [this message]
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=87ed4hrp45.fsf@oracle.com \
    --to=ankur.a.arora@oracle.com \
    --cc=bigeasy@linutronix.de \
    --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