Messages in this thread | | | Subject | When should we use likely() / unlikely() / get_unaligned() ? | From | David Woodhouse <> | Date | Fri, 06 Feb 2004 11:06:19 +0000 |
| |
There seems to be no coherent answer to the above questions. On some architectures likely() might bypass dynamic branch prediction, so we shouldn't use it unless there's at _least_ a 95% probability; on others it may simply affect code ordering and we gain a tiny benefit from it if the probabilities aren't precisely 50/50.
Likewise for using get_unaligned() to inline the alignment fixups -- what is the ratio between the costs of inlining the fixup and of potentially taking the exception? If the pointer is expected to be unaligned 25% of the time, should we use get_unaligned? What if it's 50%? 75%?
These are all very arch-specific, and sometimes compiler-specific. The likely()/unlikely()/get_unaligned() functions as they currently stand make little sense.
I think we need to include a probability, in order for use of these functions in _generic_ code to make any sense. So we replace likely(condition) with probable(condition, percentage), and likewise with get_unaligned()...
#define ARCH_PROBABILITY_HIGH 75 // These actually defined by arch code #define ARCH_PROBABILITY_LOW 25 #define ARCH_ALIGNMENT_COST_THRESHOLD 50
#define probable(condition, pc) \ (__builtin_constant_p(pc)? \ (((pc) > ARCH_PROBABILITY_HIGH)? \ __builtin_expect((condition),1): \ (((pc) < ARCH_PROBABILITY_LOW)? \ __builtin_expect((condition),0): \ (condition))) \ :(condition))
#define get_unaligned_p(ptr, pc) \ ((__builtin_constant_p(pc)&&(pc) < ARCH_ALIGNMENT_COST_THRESHOLD)? \ (*(ptr)):get_unaligned(ptr))
In fact some uClinux architectures _cannot_ fix up alignment, and would set ARCH_ALIGNMENT_COST_THRESHOLD to zero.
-- 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/
| |