All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, rth@twiddle.net
Subject: Re: When should we use likely() / unlikely() / get_unaligned() ?
Date: Sun, 8 Feb 2004 21:43:35 +1100	[thread overview]
Message-ID: <20040208214335.58f351d4.rusty@rustcorp.com.au> (raw)
In-Reply-To: <1076065578.16147.72.camel@hades.cambridge.redhat.com>

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

  reply	other threads:[~2004-02-08 10:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-06 11:06 When should we use likely() / unlikely() / get_unaligned() ? David Woodhouse
2004-02-08 10:43 ` Rusty Russell [this message]
2004-02-08 11:13   ` David Woodhouse
2004-02-08 23:00     ` Rusty Russell
2004-02-08 23:06       ` David Woodhouse
2004-02-08 23:11       ` David S. Miller
2004-02-08 23:14         ` David Woodhouse
2004-02-16 11:39     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040208214335.58f351d4.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.