Mulyadi Santosa wrote:
Hello everyone...
Many times I read about slow path and fast path during some kernel
development talks. What are they? My raw understanding is,
I've cut the rest of your email, because you interpreted
the terms wrong :)
In general, "fast path" is the commonly run code that should
finish very quickly. For example, when it comes to spinlocks
the fast path is that nobody is holding the spinlock and the
CPU that wants it can just take it.
Conversely, the slow path for spinlocks is that the lock is
already taken by somebody else and the CPU will have to wait
for the lock to be freed.
The first case is the common one that should be optimized.
The second one is not as important and does not need to be
optimized much at all.
In this example, the reason for not optimizing the spinlock
code for dealing with lock contention is that locks should
not be contended. If they are, we need to redesign the data
structures or the code to avoid contention in the first place!
You will see similar tradeoffs in the page locking code, the
scheduler code (common cases are fast, unlikely things are
put out of line by the compiler and are "behind a jump") and
many other places in the kernel.
Anybody volunteering to turn this email into an FAQ on the
kernelnewbies.org wiki? :)
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
