public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Jim Rees <rees@umich.edu>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	linux-nfs@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] NFS: kmalloc() doesn't return an ERR_PTR()
Date: Tue, 15 May 2012 16:06:36 +0000	[thread overview]
Message-ID: <4FB27F0C.30306@panasas.com> (raw)
In-Reply-To: <20120515152735.GA11230@umich.edu>

On 05/15/2012 06:27 PM, Jim Rees wrote:

> Boaz Harrosh wrote:
> 
>   > Normally we wouldn't put an unlikely() here.  It makes the code
>   > less readable and it's not going to affect benchmarks.  But I can
>   > add one if people prefer.
>   > 
> 
>   Personally It makes it more readable for me. It's like a statement:
>   "error, always slow-path case here". I have brain parsers set
>   for these.
> 
> Personally I don't like it.  It's a hint for the compiler.  Remember when
> code was liberally sprinkled with "register" modifiers on local variables?
> Turned out the compiler was smarter than we were, and those modifiers were
> hurting performance.  I'd rather let the compiler decide how to optimize.


Actually the compiler cannot. This is specifying: 
  "against all judgment I consider this path as the cold path, even if it is
   taken more times or generates less compact code. Remove this branch from
   branch prediction permanently, and never pre-fetch this path"

Again for me it's a programming style programmer-to-programmer hint. And is
very unlike "register".

The Kernel style does use unlikely() extensively in error paths, so it's not
only me. I'm not sure what the official stance is though.

I agree that it's all just shop talk ;-)

Thanks
Boaz

  reply	other threads:[~2012-05-15 16:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14 19:45 [patch] NFS: kmalloc() doesn't return an ERR_PTR() Dan Carpenter
2012-05-15 13:48 ` Boaz Harrosh
2012-05-15 13:57   ` Dan Carpenter
2012-05-15 14:18     ` Boaz Harrosh
2012-05-15 15:27       ` Jim Rees
2012-05-15 16:06         ` Boaz Harrosh [this message]
2012-05-15 16:49       ` walter harms
2012-05-16  0:38         ` Peng Tao

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=4FB27F0C.30306@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    /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