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 S1752748AbbCaTkR (ORCPT <rfc822;w@1wt.eu>);
	Tue, 31 Mar 2015 15:40:17 -0400
Received: from mga02.intel.com ([134.134.136.20]:13923 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751595AbbCaTkL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 31 Mar 2015 15:40:11 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.11,503,1422950400"; 
   d="scan'208";a="549112688"
Date: Tue, 31 Mar 2015 15:40:05 -0400
From: Matthew Wilcox <willy@linux.intel.com>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: Dan Williams <dan.j.williams@intel.com>, 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>,
        Christoph Hellwig <hch@lst.de>
Subject: Re: [Linux-nvdimm] [PATCH 4/6] SQUSHME: pmem: Micro cleaning
Message-ID: <20150331194005.GT4003@linux.intel.com>
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>
 <551ABC26.3000008@plexistor.com>
 <CAPcyv4iBjN6h_o+---mt9b5nXr-mC_famL_Od9PCDZByz959MQ@mail.gmail.com>
 <551AC0AC.6080205@plexistor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <551AC0AC.6080205@plexistor.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 31, 2015 at 06:43:40PM +0300, Boaz Harrosh wrote:
> But not here. This is not an optimization this is the *error path*.
> What I'm saying is:
> 	"No compiler nor CPU, even if 99% of the time this branch is taken
>          I still consider it cold. Because it is the error case and
>          I do not care for it"

GCC already understands that "if (foo) goto FORWARD_LABEL" should be
predicted unlikely by default.  All you're doing is cluttering the
source code.