Re: When should we use likely() / unlikely() / get_unaligned() ?

[David Woodhouse <dwmw2@infradead.org>]

On Sun, 2004-02-08 at 21:43 +1100, Rusty Russell wrote:
> Sometimes, unlikely()/likely() help code readability.  But generally it
> should be considered the register keyword of the 2000's: if the case isn't
> ABSOLUTELY CRYSTAL CLEAR, or doesn't show up on benchmarks, distain is
> appropriate.

Yes, that seems like a reasonable enough answer for likely()/unlikely()
-- use it only when it's 95% correct, and that way it's sane on all
architectures. The rest we ought to be able to leave to gcc.

To be honest, I'm more interested in the case of get_unaligned(). The
principle is fairly similar -- the ratio between the performance of the
inline and the exception cases varies wildly from architecture to
architecture. But the range is far wider -- we now support architectures
in 2.6 where alignment fixups _cannot_ happen, and the cost of the
'exception' case should be considered infinite.

A probability argument for get_unaligned() allows those architectures to
_unconditionally_ emit inline unaligned load/store code, while allowing
other, saner, architectures to start doing so only when the probability
means it makes sense.

The alternative would be a get_unlikely_unaligned() which does the same
as our current get_unaligned() on architectures without fixups, but
which is a direct dereference on others. I think I'd prefer the
probability approach though, because it allows us to tune the threshold
for all arches. 

-- 
dwmw2