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

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

[David Woodhouse]

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

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

[Rusty Russell]

On Fri, 06 Feb 2004 11:06:19 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> 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.

Yes, agreed.  But many unlikely() macros are simply there because gcc isn't
smart enough yet:

eg. fs/read_write.c:

		if (unlikely(put_user(pos, offset)))
			return -EFAULT;

It'd be better to have gcc know that this function was unlikely to return
a -ve value, and derive all the error paths itself.

It'd also be nice to be able to mark eg. printk() and BUG() as fundamentally
unlikely.

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.

Cheers,
Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

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

[David Woodhouse]

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

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

[Rusty Russell]

In message <1076238833.12587.229.camel@imladris.demon.co.uk> you write:
> 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.

Um, we do?  I thought it was compulsory in the kernel, otherwise
networking breaks on packets w/ wierd hardware headers.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

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

[David Woodhouse]

On Mon, 2004-02-09 at 10:00 +1100, Rusty Russell wrote:
> > we now support architectures in 2.6 where alignment fixups _cannot_ happen,
> > and the cost of the 'exception' case should be considered infinite.
> 
> Um, we do?  I thought it was compulsory in the kernel, otherwise
> networking breaks on packets w/ wierd hardware headers.

We do. It breaks. I'm trying to come up with a solution for it which
actually lets us optimise elsewhere too, and hence has at least a
whelk's chance in a supernova of being accepted... :)

-- 
dwmw2

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

[David S. Miller]

On Mon, 09 Feb 2004 10:00:47 +1100
Rusty Russell <rusty@rustcorp.com.au> wrote:

> Um, we do?  I thought it was compulsory in the kernel, otherwise
> networking breaks on packets w/ wierd hardware headers.

That's right, for the old old ARMs they've always been broken
with certain types of encapsulations due to this.  Even just feed
them certain kinds of odd TCP/IP option sequences and watch the
packet handling work on corrupted header data on such older ARMs.

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

[David Woodhouse]

On Sun, 2004-02-08 at 15:11 -0800, David S. Miller wrote:
> That's right, for the old old ARMs they've always been broken
> with certain types of encapsulations due to this.  Even just feed
> them certain kinds of odd TCP/IP option sequences and watch the
> packet handling work on corrupted header data on such older ARMs.

With the merge of uCLinux there are more machines like this too. I've
been playing with one recently where alignment exceptions are imprecise
:)

Adding a probability to get_unaligned() lets _all_ architectures set
their own optimal threshold for when to emit inline load/store code, and
when to take the exception.... and the ones which will set that
threshold at 0% become an arch-specific special case which you really
don't have to care about.

-- 
dwmw2

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

[Pavel Machek]

Hi!

> 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

I think that this alternative is way better than introducing
probabilities.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms