From: Thomas Gleixner <tglx@linutronix.de>
To: Ankur Arora <ankur.a.arora@oracle.com>,
Joel Fernandes <joel@joelfernandes.org>
Cc: paulmck@kernel.org, Ankur Arora <ankur.a.arora@oracle.com>,
linux-kernel@vger.kernel.org, peterz@infradead.org,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de,
jpoimboe@kernel.org, mark.rutland@arm.com, jgross@suse.com,
andrew.cooper3@citrix.com, bristot@kernel.org,
mathieu.desnoyers@efficios.com, geert@linux-m68k.org,
glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com,
mattst88@gmail.com, krypton@ulrich-teichert.org,
rostedt@goodmis.org, David.Laight@aculab.com, richard@nod.at,
mjguzik@gmail.com, jon.grimm@amd.com, bharata@amd.com,
raghavendra.kt@amd.com, boris.ostrovsky@oracle.com,
konrad.wilk@oracle.com, rcu@vger.kernel.org
Subject: Re: [PATCH 15/30] rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y
Date: Mon, 11 Mar 2024 23:12:15 +0100 [thread overview]
Message-ID: <87il1spge8.ffs@tglx> (raw)
In-Reply-To: <877ci8h4pc.fsf@oracle.com>
On Mon, Mar 11 2024 at 13:51, Ankur Arora wrote:
> Joel Fernandes <joel@joelfernandes.org> writes:
>>> Why not key off of the value of CONFIG_PREEMPT_DYNAMIC? That way,
>>> if both CONFIG_PREEMPT_AUTO=y and CONFIG_PREEMPT_DYNAMIC=y, RCU is
>>> always preemptible. Then CONFIG_PREEMPT_DYNAMIC=y enables boot-time
>>> (and maybe even run-time) switching between preemption flavors, while
>>> CONFIG_PREEMPT_AUTO instead enables unconditional preemption of any
>>> region of code that has not explicitly disabled preemption (or irq or
>>> bh or whatever).
>
> Currently CONFIG_PREEMPT_DYNAMIC does a few things:
>
> 1. dynamic selection of preemption model
> 2. dynamically toggling explicit preemption points
> 3. PREEMPT_RCU=y (though maybe this should be fixed to also
> also allow PREEMPT_RCU=n)
>
> Of these 3, PREEMPT_AUTO only really needs (1).
>
> Maybe combining gives us the option of switching between the old and the
> new models:
> preempt=none | voluntary | full | auto-none | auto-voluntary
>
> Where the last two provide the new auto semantics. But, the mixture
> seems too rich.
> This just complicates all the CONFIG_PREEMPT_* configurations more than
> they were before when the end goal is to actually reduce and simplify
> the number of options.
>
>> That could be done. But currently, these patches disable DYNAMIC if AUTO is
>> enabled in the config. I think the reason is the 2 features are incompatible.
>> i.e. DYNAMIC wants to override the preemption mode at boot time, where as AUTO
>> wants the scheduler to have a say in it using the need-resched LAZY bit.
>
> Yeah exactly. That's why I originally made PREEMPT_AUTO and
> PREEMPT_DYNAMIC exclusive of each other.
Rightfully so. The purpose of PREEMPT_AUTO is to get rid of
PREEMPT_DYNAMIC and not to proliferate the existance of it.
There is no point. All what AUTO wants to provide at configuration time
is the default model. So what would DYNAMIC buy what AUTO does not
provide trivially with a single sysfs knob which only affects the
scheduler where the decisions are made and nothing else?
The only extra config knob is PREEMPT_RCU which as we concluded long ago
needs to support both no and yes when AUTO is selected up to the point
where that model can be switched at boot time too.
Seriously, keep this stuff simple and straight forward and keep the real
goals in focus:
1) Simplify the preemption model zoo
2) Get rid of the ill defined cond_resched()/might_sleep() hackery
All the extra - pardon my french - ivory tower wankery on top is not
helpful at all. We can debate this forever on a theoretical base and
never get anywhere and anything done.
Please focus on getting the base mechanics in place with the required
fixes for the fallout for preemptible and non-preemtible RCU (selected
at compile time) and work it out from there.
Perfect it the enemy of good. Especially when nobody can come up with a
perfect definition what 'perfect' actually means.
Thanks,
tglx
next prev parent reply other threads:[~2024-03-11 22:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240213055554.1802415-1-ankur.a.arora@oracle.com>
[not found] ` <20240213055554.1802415-16-ankur.a.arora@oracle.com>
2024-03-10 10:03 ` [PATCH 15/30] rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y Joel Fernandes
2024-03-10 18:56 ` Paul E. McKenney
2024-03-11 0:48 ` Joel Fernandes
2024-03-11 3:56 ` Paul E. McKenney
2024-03-11 15:01 ` Joel Fernandes
2024-03-11 20:51 ` Ankur Arora
2024-03-11 22:12 ` Thomas Gleixner [this message]
2024-03-11 5:18 ` Ankur Arora
2024-03-11 15:25 ` Joel Fernandes
2024-03-11 19:12 ` Thomas Gleixner
2024-03-11 19:53 ` Paul E. McKenney
2024-03-11 20:29 ` Thomas Gleixner
2024-03-12 0:01 ` Paul E. McKenney
2024-03-12 0:08 ` Joel Fernandes
2024-03-12 3:16 ` Ankur Arora
2024-03-12 3:24 ` Joel Fernandes
2024-03-12 5:23 ` Ankur Arora
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=87il1spge8.ffs@tglx \
--to=tglx@linutronix.de \
--cc=David.Laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=ankur.a.arora@oracle.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=bharata@amd.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=bristot@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joel@joelfernandes.org \
--cc=jon.grimm@amd.com \
--cc=jpoimboe@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=krypton@ulrich-teichert.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mattst88@gmail.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=rcu@vger.kernel.org \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=willy@infradead.org \
/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