[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r0loiy3y.fsf@oracle.com>
Date: Fri, 20 Oct 2023 18:05:21 -0700
From: Ankur Arora <ankur.a.arora@...cle.com>
To: paulmck@...nel.org
Cc: Ankur Arora <ankur.a.arora@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
akpm@...ux-foundation.org, luto@...nel.org, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, mingo@...hat.com,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
willy@...radead.org, mgorman@...e.de, rostedt@...dmis.org,
jon.grimm@....com, bharata@....com, raghavendra.kt@....com,
boris.ostrovsky@...cle.com, konrad.wilk@...cle.com,
jgross@...e.com, andrew.cooper3@...rix.com,
Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED
Paul E. McKenney <paulmck@...nel.org> writes:
> On Fri, Oct 20, 2023 at 03:56:38PM -0700, Ankur Arora wrote:
>>
>> Paul E. McKenney <paulmck@...nel.org> writes:
>>
>> > Thomas!
>> >
>> > On Thu, Oct 19, 2023 at 02:21:35AM +0200, Thomas Gleixner wrote:
>> >> Paul!
>> >>
>> >> On Wed, Oct 18 2023 at 10:19, Paul E. McKenney wrote:
>> >> > On Wed, Oct 18, 2023 at 03:16:12PM +0200, Thomas Gleixner wrote:
>> >> >> On Tue, Oct 17 2023 at 18:03, Paul E. McKenney wrote:
>> >> >> In the end there is no CONFIG_PREEMPT_XXX anymore. The only knob
>> >> >> remaining would be CONFIG_PREEMPT_RT, which should be renamed to
>> >> >> CONFIG_RT or such as it does not really change the preemption
>> >> >> model itself. RT just reduces the preemption disabled sections with the
>> >> >> lock conversions, forced interrupt threading and some more.
>> >> >
>> >> > Again, please, no.
>> >> >
>> >> > There are situations where we still need rcu_read_lock() and
>> >> > rcu_read_unlock() to be preempt_disable() and preempt_enable(),
>> >> > repectively. Those can be cases selected only by Kconfig option, not
>> >> > available in kernels compiled with CONFIG_PREEMPT_DYNAMIC=y.
>> >>
>> >> Why are you so fixated on making everything hardcoded instead of making
>> >> it a proper policy decision problem. See above.
>> >
>> > Because I am one of the people who will bear the consequences.
>> >
>> > In that same vein, why are you so opposed to continuing to provide
>> > the ability to build a kernel with CONFIG_PREEMPT_RCU=n? This code
>> > is already in place, is extremely well tested, and you need to handle
>> > preempt_disable()/preeempt_enable() regions of code in any case. What is
>> > the real problem here?
>>
[ snip ]
>> As far as I can tell (which isn't all that far), TREE_RCU=y makes strictly
>> stronger forward progress guarantees with respect to rcu readers (in
>> that they can't be preempted.)
>
> TREE_RCU=y is absolutely required if you want a kernel to run on a system
> with more than one CPU, and for that matter, if you want preemptible RCU,
> even on a single-CPU system.
>
>> So, can PREEMPTION=y run with, say TREE_RCU=y? Or maybe I'm missing something
>> obvious there.
>
> If you meant to ask about PREEMPTION and PREEMPT_RCU, in theory, you
> can run any combination:
Sorry, yes I did. Should have said "can PREEMPTION=y run with, (TREE_RCU=y,
PREEMPT_RCU=n).
> PREEMPTION && PREEMPT_RCU: This is what we use today for preemptible
> kernels, so this works just fine (famous last words).
>
> PREEMPTION && !PREEMPT_RCU: A preemptible kernel with non-preemptible
> RCU, so that rcu_read_lock() is preempt_disable() and
> rcu_read_unlock() is preempt_enable(). This should just work,
> except for the fact that cond_resched() disappears, which
> stymies some of RCU's forward-progress mechanisms. And this
> was the topic of our earlier discussion on this thread. The
> fixes should not be too hard.
>
> Of course, this has not been either tested or used for at least
> eight years, so there might be some bitrot. If so, I will of
> course be happy to help fix it.
>
>
> !PREEMPTION && PREEMPT_RCU: A non-preemptible kernel with preemptible
> RCU. Although this particular combination of Kconfig
> options has not been tested for at least eight years, giving
> a kernel built with CONFIG_PREEMPT_DYNAMIC=y the preempt=none
> kernel boot parameter gets you pretty close. Again, there is
> likely to be some bitrot somewhere, but way fewer bits to rot
> than for PREEMPTION && !PREEMPT_RCU. Outside of the current
> CONFIG_PREEMPT_DYNAMIC=y case, I don't see the need for this
> combination, but if there is a need and if it is broken, I will
> be happy to help fix it.
>
> !PREEMPTION && !PREEMPT_RCU: A non-preemptible kernel with non-preemptible
> RCU, which is what we use today for non-preemptible kernels built
> with CONFIG_PREEMPT_DYNAMIC=n. So to repeat those famous last
> works, this works just fine.
>
> Does that help, or am I missing the point of your question?
It does indeed. What I was going for, is that this series (or, at
least my adaptation of TGLX's PoC) wants to keep CONFIG_PREEMPTION
in spirit, while doing away with it as a compile-time config option.
That it does, as TGLX mentioned upthread, by moving all of the policy
to the scheduler, which can be tuned by user-space (via sched-features.)
So, my question was in response to this:
>> > In that same vein, why are you so opposed to continuing to provide
>> > the ability to build a kernel with CONFIG_PREEMPT_RCU=n? This code
>> > is already in place, is extremely well tested, and you need to handle
>> > preempt_disable()/preeempt_enable() regions of code in any case. What is
>> > the real problem here?
Based on your response the (PREEMPT_RCU=n, TREE_RCU=y) configuration
seems to be eminently usable with this configuration.
(Or maybe I'm missed the point of that discussion.)
On a related note, I had started rcutorture on a (PREEMPTION=y, PREEMPT_RCU=n,
TREE_RCU=y) kernel some hours ago. Nothing broken (yet!).
--
ankur
Powered by blists - more mailing lists