Ehh.. On most architectures an unconditional direct function call is
_faster_ than a conditional test that does not predict all that well. So
the "test is faster than a function call" is not a very good optimization,
I suspect.
In fact, we'd probably be better off trying to factor out more out of
schedule() rather than making it even bigger. We've done that before: the
timeout stuff was done that way, and meant that normal reschedules no
longer need to care about timeouts. That made things simpler.
On the other hand, we do have other ways to test the preempt count inside
the scheduler. In particular, we might just move the "in_atomic()" check a
few lines downwards, at which point we've released the kernel lock and
explicitly disabled preemption, so at that point the test should be even
simpler with fewer conditionals..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/