[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150513101744.GA4318@gmail.com>
Date: Wed, 13 May 2015 12:17:44 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Denys Vlasenko <dvlasenk@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Graf <tgraf@...g.ch>,
"David S. Miller" <davem@...emloft.net>,
Bart Van Assche <bvanassche@....org>,
Peter Zijlstra <peterz@...radead.org>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] force inlining of spinlock ops
* Denys Vlasenko <dvlasenk@...hat.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists