Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754203AbbEMKRv (ORCPT ); Wed, 13 May 2015 06:17:51 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:34766 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753565AbbEMKRt (ORCPT ); Wed, 13 May 2015 06:17:49 -0400 Date: Wed, 13 May 2015 12:17:44 +0200 From: Ingo Molnar To: Denys Vlasenko Cc: Linus Torvalds , Thomas Graf , "David S. Miller" , Bart Van Assche , Peter Zijlstra , David Rientjes , Andrew Morton , Oleg Nesterov , "Paul E. McKenney" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] force inlining of spinlock ops Message-ID: <20150513101744.GA4318@gmail.com> References: <1431367042-31475-1-git-send-email-dvlasenk@redhat.com> <20150512074443.GA724@gmail.com> <5551DDBD.9010803@redhat.com> <20150512114353.GA13699@gmail.com> <5551FC76.40000@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5551FC76.40000@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1856 Lines: 57 * Denys Vlasenko wrote: > On 05/12/2015 01:43 PM, Ingo Molnar wrote: > >>> Furtermore, what is the size win on x86 defconfig with these options > >>> set? > >> > >> CONFIG_OPTIMIZE_INLINING=y is in defconfig. > >> > >> Size difference for CC_OPTIMIZE_FOR_SIZE: > >> > >> text data bss dec hex filename > >> 12335864 1746152 1081344 15163360 e75fe0 vmlinux.CC_OPTIMIZE_FOR_SIZE=y > >> 10373764 1684200 1077248 13135212 c86d6c vmlinux.CC_OPTIMIZE_FOR_SIZE=n > >> > >> Decrease by about 19%. > > > > I suspect the 'filename' field wants to be flipped? > > Yes. > > > In any case, the interesting measurement would not be -Os comparisons > > (which causes GCC to be too crazy), but to see the size effect of your > > _patch_ that always-inlines spinlock ops, on plain defconfig and on > > defconfig-Os. > > Here it is: > > text data bss dec hex filename > 12335864 1746152 1081344 15163360 e75fe0 vmlinuxO2.before > 12335930 1746152 1081344 15163426 e76022 vmlinux Hm, that's a (small) size increase on O2. That might be a net positive though: because now we've eliminated quite a few function calls. Do we know which individual functions bloat and which debloat? > text data bss dec hex filename > 10373764 1684200 1077248 13135212 c86d6c vmlinuxOs.before > 10363621 1684200 1077248 13125069 c845cd vmlinux A decrease - which gets exploded on allyesconfig. So as long as the -O2 case does not get hurt we can do -Os fixes. I think this needs a bit more work to ensure that the O2 case is a net win. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/