![]() | |||||||||||||
Messages in this thread |
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 - 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/ | ||||||||||||
| Last update: 2005-03-22 13:00 [from the cache] ©2003-2008 | |||||||||||||