* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
On Tue, Sep 19 2023 at 10:25, Linus Torvalds wrote:
On Tue, 19 Sept 2023 at 06:48, John Paul Adrian Glaubitz
<glaubitz@xxxxxxxxxxxxxxxxxxx> wrote:
As Geert poined out, I'm not seeing anything particular problematic with the
architectures lacking CONFIG_PREEMPT at the moment. This seems to be more
something about organizing KConfig files.
It can definitely be problematic.
Not the Kconfig file part, and not the preempt count part itself.
But the fact that it has never been used and tested means that there
might be tons of "this architecture code knows it's not preemptible,
because this architecture doesn't support preemption".
So you may have basic architecture code that simply doesn't have the
"preempt_disable()/enable()" pairs that it needs.
PeterZ mentioned the generic entry code, which does this for the entry
path. But it actually goes much deeper: just do a
git grep preempt_disable arch/x86/kernel
and then do the same for some other architectures.
Looking at alpha, for example, there *are* hits for it, so at least
some of the code there clearly *tries* to do it. But does it cover all
the required parts? If it's never been tested, I'd be surprised if
it's all just ready to go.
I do think we'd need to basically continue to support ARCH_NO_PREEMPT
- and such architectures migth end up with the worst-cast latencies of
only scheduling at return to user space.
The only thing these architectures should gain is the preempt counter
itself, [...]
And if any of these machines are still used, there's the small benefit of
preempt_count increasing debuggability of scheduling in supposedly
preempt-off sections that were ignored silently previously, as most of
these architectures do not even enable CONFIG_DEBUG_ATOMIC_SLEEP=y in their
defconfigs:
$ for ARCH in alpha hexagon m68k um; do git grep DEBUG_ATOMIC_SLEEP arch/$ARCH; done
$
Plus the efficiency of CONFIG_DEBUG_ATOMIC_SLEEP=y is much reduced on
non-PREEMPT kernels to begin with: it will basically only detect scheduling
in hardirqs-off critical sections.
So IMHO there's a distinct debuggability & robustness plus in enabling the
preemption count on all architectures, even if they don't or cannot use the
rescheduling points.
[...] but yes the extra preemption points are not mandatory to have, i.e.
we simply do not enable them for the nostalgia club.
The removal of cond_resched() might cause latencies, but then I doubt
that these museus pieces are used for real work :)
I'm not sure we should initially remove *explicit* legacy cond_resched()
points, except from high-freq paths where they hurt - and of course remove
them from might_sleep().
Thanks,
Ingo
