The reason of not executing the trylock in the slow path of the lock_page is to
avoid writing to the shared ram on all the CPUs at the same time for no good
We can write just now to the same cacheline from all the CPUs at the same time
if all the cpus runs lock_page at the same time on the same page, but there's
not an high probability for such thing to happen and we would be slower to try
to read first.
The reason of the `continue' is only one: if the wakeup would be wake-all we
would end executing NR_sleppers TryLockPage() and we would get an high probability
that only one of those trylocks will succeed. So we could assume that all the
other trylocks was going to be wasted and so we used `continue' to try not to
bang the cacheline too much for probably no good reason.
But since it's a wake-one, only one task will try to acquire the cacheline after
the wakeup as it just did once with the TryLockPage in lock_page(). It will
just try again like restarting from lock_page().
I don't see how the probability of TryLockPage to succeed after the wakeup
could decrease compared to the first TryLockPage. Since the probability doesn't
decrease I don't see any point for the `continue'. Why should the probability
of succeeding in TryLockPage drecrease after a wakeup compared to the
TryLockPage in lock_page()? If you have an explanation I will certainly agree
to left the `continue' there.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/