From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id 01D5A2C72 for <dev@dpdk.org>; Mon, 6 Jul 2015 11:27:49 +0200 (CEST) Received: by wifm2 with SMTP id m2so23696357wif.1 for <dev@dpdk.org>; Mon, 06 Jul 2015 02:27:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=fchc2yer5vYG8+GW0YJWHyBiblweOa1RyAJEkIXgbTE=; b=ZcmYzIYvDpwLLiKk78wxBLb+fAeLZ5ZWOYlqpYo2nuaJcsujw0fUymJbAlw0tFX7/z TMyZBIxikNIBMQhgZxYUfeSZQHMtbWyUKQ3Tc5n+abp0A+p93HOawECgBEmmzru651IQ mC5cV/p1bn5FAx2h55A+0E2Djy64SCn/geaucWjqspCyZ4WXvA3JaSXzzD0j/UbbZRUI 5KB2W9TCN46LnYBdZoVnvs1WArWZjYr5qQXqETOg9G0NWkxZ/mYb59Fs5BYAzQq1P9+A mZ8c5/DkuGLc1bGsSkJhFP6JhmfPy9Mk+qXs4dIQsA3tbfX3G8QyliEMfUwL17ppWYy5 zCWg== X-Gm-Message-State: ALoCoQlvhHeyQTuW8jU763hScsaaIoa9WmRl20DY46lM2+z01191jTqYw0WeC0SD56/K1rnSzpf/ X-Received: by 10.194.122.132 with SMTP id ls4mr4817578wjb.130.1436174869843; Mon, 06 Jul 2015 02:27:49 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ej5sm27115485wjd.22.2015.07.06.02.27.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 02:27:49 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Bruce Richardson <bruce.richardson@intel.com> Date: Mon, 06 Jul 2015 11:26:40 +0200 Message-ID: <32645498.dLKnnNxHfe@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150706092050.GB348@bricha3-MOBL3> References: <1435938006-22254-1-git-send-email-bruce.richardson@intel.com> <2644782.PAW8lcSTnr@xps13> <20150706092050.GB348@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 06 Jul 2015 09:27:50 -0000 2015-07-06 10:20, Bruce Richardson: > 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. No concern. I was only interested to fully understand why you made this change. Thanks