Cc: Paul E. McKenney <paulmck@...>, H. Peter Anvin <hpa@...>, Jeremy Fitzhardinge <jeremy@...>, Andrew Morton <akpm@...>, Ingo Molnar <mingo@...>, Joe Perches <joe@...>, <linux-kernel@...>, Steven Rostedt <rostedt@...>
EXACTLY.
It's not even necessarily a "contention" bit per se - it's literally a
"readers have to take the slow-path" bit (writers will obviously _always_
take the slowpath if there is any non-zero value at all, so they don't
need it).
Then, the slow-path might actually decide that "hey, there is no _actual_
writer there yet - just some _waiting_ writer, but since this read lock is
in an interrupt context, we have to let it go through _despite_ the fact
that the lock is contended in order to avoid deadlock".
So it allows a fast-path for the trivial cases that is literally just a
couple of instructions long, and that is nice not just because of
performance issues, but because it then means that you can entirely ignore
all those things in the slow path. It also means that everybody can look
at the fast-path and decide that "ok, the fast-path really is optimal".
That fast-path is what a lot of people care more about than just about
anything else.
The slow-path, in comparison, can be in C, and can do all those checks
like "are we in an (sw-)interrupt handler?" and basically prioritize
certain classes of people.
Linus
--
