Re: [PATCH] force inlining of spinlock ops

[Denys Vlasenko]

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/