Messages in this thread | | | Date | Wed, 13 May 2015 12:43:05 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |