From: Jens Axboe <axboe@suse.de>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: Neil Brown <neilb@cse.unsw.edu.au>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.5.20 RAID5 compile error
Date: Wed, 5 Jun 2002 12:19:47 +0200 [thread overview]
Message-ID: <20020605101947.GZ1105@suse.de> (raw)
In-Reply-To: <15612.43734.121255.771451@notabene.cse.unsw.edu.au> <20020604115842.GA5143@suse.de> <15612.44897.858819.455679@notabene.cse.unsw.edu.au> <20020604122105.GB1105@suse.de> <20020604123205.GD1105@suse.de> <20020604123856.GE1105@suse.de> <20020604142327.GN1105@suse.de> <3CFCC467.7060702@evision-ventures.com> <20020604145528.GQ1105@suse.de> <3CFCCD91.4020308@evision-ventures.com>
On Tue, Jun 04 2002, Martin Dalecki wrote:
> >WRT the unlikely(), if you have the hints available, why not pass them
> >on?
>
> Well it's kind like the answer to the question: why don't do it all in hand
> optimized assembler? Or in other words - let's give the GCC guys good
[snip]
If I didn't know better Martin, I would say that you are trolling.
Surely you have better ways to spend your time than to fly fuck [1]
every single patch posted on lkml? :-)
I would agree with your entire email if you were talking about inlining.
Yes we should not inline excessively without a good reason. However, the
likely/unlikely hints provide both clues to the code reader (as someone
else already established) about which is the likely code path or not,
and of course to the compiler. I would agree that profiling would in
some cases be needed before slapping on an unlikely() sticker. These are
the cases where you do not know what the call path is typically like.
When I put unlikely() in there, it's because I know there's a 1:50 ratio
or more. Or maybe a 1:inf ratio, meaning it should only trigger because
of a bug.
[1] To "fuck a fly" is a danish expression, meaning excessive attention
to detail.
--
Jens Axboe
next prev parent reply other threads:[~2002-06-05 10:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-03 18:36 2.5.20 RAID5 compile error Mike Black
2002-06-04 11:51 ` Jens Axboe
2002-06-04 11:56 ` Neil Brown
2002-06-04 11:58 ` Jens Axboe
2002-06-04 12:15 ` Neil Brown
2002-06-04 12:21 ` Jens Axboe
2002-06-04 12:32 ` Jens Axboe
2002-06-04 12:38 ` Jens Axboe
2002-06-04 14:23 ` Jens Axboe
2002-06-04 13:45 ` Martin Dalecki
2002-06-04 14:55 ` Jens Axboe
2002-06-04 14:24 ` Martin Dalecki
2002-06-04 18:22 ` Horst von Brand
2002-06-05 10:19 ` Jens Axboe [this message]
2002-06-04 17:00 ` Ingo Oeser
2002-06-05 1:16 ` Neil Brown
2002-06-05 10:13 ` Jens Axboe
2002-06-06 2:58 ` Neil Brown
2002-06-06 5:31 ` Jens Axboe
2002-06-04 21:48 ` Miles Lane
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=20020605101947.GZ1105@suse.de \
--to=axboe@suse.de \
--cc=dalecki@evision-ventures.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox