From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 713EF2E7B for ; Mon, 6 Jul 2015 11:20:55 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 06 Jul 2015 02:20:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,414,1432623600"; d="scan'208";a="600781200" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.62]) by orsmga003.jf.intel.com with SMTP; 06 Jul 2015 02:20:53 -0700 Received: by (sSMTP sendmail emulation); Mon, 06 Jul 2015 10:20:51 +0025 Date: Mon, 6 Jul 2015 10:20:51 +0100 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20150706092050.GB348@bricha3-MOBL3> References: <1435938006-22254-1-git-send-email-bruce.richardson@intel.com> <2430733.IxTGXH4ElX@xps13> <20150703155642.GB8096@bricha3-MOBL3> <2644782.PAW8lcSTnr@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2644782.PAW8lcSTnr@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/2] ixgbe: add "cold" attribute to setup/teardown fns X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:20:56 -0000 On Fri, Jul 03, 2015 at 09:57:26PM +0200, Thomas Monjalon wrote: > 2015-07-03 16:56, Bruce Richardson: > > On Fri, Jul 03, 2015 at 05:45:34PM +0200, Thomas Monjalon wrote: > > > Hi Bruce, > > > > > > 2015-07-03 16:40, Bruce Richardson: > > > > As well as the fast-path functions in the rxtx code, there are also > > > > functions which set up and tear down the descriptor rings. Since these > > > > are not performance critical functions, there is no need to have them > > > > extensively optimized, so we add __attribute__((cold)) to their > > > > definitions. This has the side-effect of making debugging them easier as > > > > the compiler does not optimize them as heavily, so more variables are > > > > accessible by default in gdb. > > > > > > What is the benefit, compared to -O0? > > > > First off, it's per function, rather than having to use -O0 globally. Secondly, > > it doesn't disable optimization, it just tells the compiler that the code is > > not on the hotpath - whether or not the compiler optimizes it is up to the > > compiler itself. From GCC documentation: > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes > > > > "The cold attribute on functions is used to inform the compiler that the > > function is unlikely to be executed. The function is optimized for size rather > > than speed and on many targets it is placed into a special subsection of the > > text section so all cold functions appear close together, improving code > > locality of non-cold parts of program. The paths leading to calls of cold > > functions within code are marked as unlikely by the branch prediction mechanism. > > It is thus useful to mark functions used to handle unlikely conditions, such as > > perror, as cold to improve optimization of hot functions that do call marked > > functions in rare occasions." > > I know it may provide some optimization of the hot path. > I was asking compared to -O0 because you were justifying this change for debug. > In other words, for debugging, -O0 is probably better. So the reason of this > change should be the optimization. And it would be interesting to know if you > have seen some performance improvement. For some cases, O0 will be necessary, but the advantage of this change is that for debugging of code that is not in the fast-path, the use of -O0 may be unnecessary - which is useful, since you don't always need to do a special debug build. As for performance impact: no, I have not seen any performance impact from this change. Personally, I view this as a low impact change that doesn't really have any negatives. Is there some concern in particular you have about it? It's really just providing some extra hints to the compiler. /Bruce