From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965104AbbJVPKE (ORCPT ); Thu, 22 Oct 2015 11:10:04 -0400 Received: from casper.infradead.org ([85.118.1.10]:60486 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756446AbbJVPKC (ORCPT ); Thu, 22 Oct 2015 11:10:02 -0400 Date: Thu, 22 Oct 2015 17:09:59 +0200 From: Peter Zijlstra To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, Liam Girdwood , linux-kernel@vger.kernel.org, Mark Brown , akpm@linux-foundation.org, Ingo Molnar Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function Message-ID: <20151022150959.GU17308@twins.programming.kicks-ass.net> References: <11282238.AHmyWliPRj@wuerfel> <20151013203812.GM17308@twins.programming.kicks-ass.net> <11817958.z9KtmeKzV7@wuerfel> <57854232.vMTrn4EgZx@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57854232.vMTrn4EgZx@wuerfel> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 22, 2015 at 05:02:45PM +0200, Arnd Bergmann wrote: > On Tuesday 13 October 2015 23:46:35 Arnd Bergmann wrote: > > On Tuesday 13 October 2015 22:38:12 Peter Zijlstra wrote: > > > A quick grep shows a large amount of trivial code that optimizers will > > > still happily throw away, but it should be verified that this does not > > > result in pointless code generation. > > > > Indeed, I'm seeing a tiny code growth with ARM multi_v7_defconfig when > > my patch is applied, as the image (according to size -A) grows from > > 13740187 bytes to 13740283, all of it in .text of two drivers (i2c-core > > and three files of bluetooth.ko). > > > Did we actually reach any conclusion here? We still get the warnings > in the regulator code in linux-next, and I'd like to see either this > patch ("mutex: make mutex_lock_nested an inline function") or > "regulator: core: avoid unused variable warning" get merged. > > We could also remove the two functions again, as they are still > unused and we are getting closer to the merge window. Hmm, I was sure I send a reply, but I cannot even find it in my own sent folder so who knows. My current preference is to keep the thing a macro and work around it in the usage site because while these warns are annoying, they're at least visible. Whereas, with an inline, code bloat is entirely silent. Even if the sites you found are harmless, there's no saying what the future will bring etc..