From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755146AbbCaPY2 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 31 Mar 2015 11:24:28 -0400
Received: from mail-wg0-f53.google.com ([74.125.82.53]:36806 "EHLO
	mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752938AbbCaPY0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 31 Mar 2015 11:24:26 -0400
Message-ID: <551ABC26.3000008@plexistor.com>
Date: Tue, 31 Mar 2015 18:24:22 +0300
From: Boaz Harrosh <boaz@plexistor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Dan Williams <dan.j.williams@intel.com>
CC: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
        linux-nvdimm <linux-nvdimm@ml01.01.org>, X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [Linux-nvdimm] [PATCH 4/6] SQUSHME: pmem: Micro cleaning
References: <1427358764-6126-1-git-send-email-hch@lst.de>	<55143A8B.2060304@plexistor.com>	<20150331092526.GA25958@lst.de>	<551A9EB3.8000605@plexistor.com>	<551AA0AD.4000604@plexistor.com> <CAPcyv4hLL0o2DHtFhBeBdZ-B5zYjXYBBbp-Xn70UMgoO-kB8vA@mail.gmail.com>
In-Reply-To: <CAPcyv4hLL0o2DHtFhBeBdZ-B5zYjXYBBbp-Xn70UMgoO-kB8vA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/31/2015 06:17 PM, Dan Williams wrote:
> On Tue, Mar 31, 2015 at 6:27 AM, Boaz Harrosh <boaz@plexistor.com> wrote:
>>
>> Some error checks had unlikely some did not. Put unlikely
>> on all error handling paths.
>> (I like unlikely for error paths specially for readability)
> 
> "unlikely()" is not a readability hint, it's specifically for branches
> that profiling shows adding it makes a difference.  Just delete them
> all until profiling show they make a difference.  They certainly don't
> make a difference in the slow paths.
> 

Why?

So we do not fill up the  branch predictor with useless predictions
that will never matter. What is so bad with that. It may be cold path
but added up all over it will show eventually.

I do not see what is the harm of telling the compiler.
    "never store any prediction for this branch"

So since it can never (ever) harm any one or anything, and at the mass
if everywhere it was done this way it could actually help, then sure
it can be a readability thing. Since no harm done, right?

I still like it

Thanks
Boaz