On Sun, Oct 18, 2020 at 8:24 PM Paul E. McKenney <paul...@kernel.org> wrote:
>
> On CONFIG_PREEMPT_COUNT, got it. It would be OK for RCU to use
> preempt_count() for some debugging or specialty kernel, but not across
> the board.
Right - that was what I thought you were asking originally.
I don't think a driver or random piece of code like that should ever
use "preempt_count()" on its own - partly because the rules are
subtle, but partly simply because drivers have no business with those
kinds of low-level things.
But yeah, for some core stuff like RCU, using preempt_count() for
debugging etc makes sense. Just not to change _behavior_, because
preempt_count on its own is almost entirely meaningless. It's just one
(local) part of so much state. Again, partly because preempt count
isn't necessarily always meaningful due to config settings, but partly
because there are just so many other things like "are interrupts
disabled" or "are we in an NMI context" or whatever.
And in some odd situation, depending on exactly what you do, maybe
preempt-count can be exactly what you need, because you know
everything else about the state statically. "preempt_enable()"
obviously is one such thing - the whole point is "if
CONFIG_PREEMPT_COUNT is on, then the _semantics_ of this is 'increase
preempt count', and if it goes to zero, and we should reschedule, do
that'".
So it's not that preempt_count() is meaningless, but it's such a
specialized thing that 99.9% of all code really cannot and shouldn't
use it.
Linus
