On Mon, 11 Sept 2023 at 13:50, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Except we've actually been *adding* to this whole mess, rather than
> removing it. So we have actively *expanded* on that preemption choice
> with PREEMPT_DYNAMIC.
Actually, that config option makes no sense.
It makes the sched_cond() behavior conditional with a static call.
But all the *real* overhead is still there and unconditional (ie all
the preempt count updates and the "did it go down to zero and we need
to check" code).
That just seems stupid. It seems to have all the overhead of a
preemptible kernel, just not doing the preemption.
So I must be mis-reading this, or just missing something important.
The real cost seems to be
PREEMPT_BUILD -> PREEMPTION -> PREEMPT_COUNT
and PREEMPT vs PREEMPT_DYNAMIC makes no difference to that, since both
will end up with that, and thus both cases will have all the spinlock
preempt count stuff.
There must be some non-preempt_count cost that people worry about.
Or maybe I'm just mis-reading the Kconfig stuff entirely. That's
possible, because this seems *so* pointless to me.
Somebody please hit me with a clue-bat to the noggin.
Linus
