lkml.org 
[lkml]   [2015]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] force inlining of spinlock ops

* Denys Vlasenko <dvlasenk@redhat.com> wrote:

> On 05/13/2015 12:17 PM, Ingo Molnar wrote:
> >>> 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.
>
> I think O2 difference is just noise: with -O2 gcc is far less prone
> to bogus deinlining, my patch should have negligible effect. And
> effect is indeed negligible: +70 bytes on 12 megabytes.

So the patch force-inlines about a dozen locking APIs:

- Some of those decrease the defconfig kernel size.
Which ones and by how much?

- Some of those increase the defconfig kernel size.
Which ones and by how much?

We only know that the net effect is +70 bytes. Does that come out of:

- large fluctuations such as -1000-1000+1000+1070, which happens to
net out into a small net number?

- or does it come from much smaller fluctuations?

So to make an informed decision we need to know those details. When I
deinline or reinline functions I usually do it on a per function
basis, to avoid such ambiguity.

In the end what we want to have is only those deinlining/reinlining
changes that decrease the defconfig kernel size, or at worst only
increase it marginally.

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-05-13 13:01    [W:0.468 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site