Messages in this thread | | | From | Nadav Amit <> | Subject | Re: [PATCH 0/5] x86/percpu semantics and fixes | Date | Fri, 8 Mar 2019 19:35:17 +0000 |
| |
> On Mar 8, 2019, at 6:50 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, Feb 27, 2019 at 11:12:52AM +0100, Peter Zijlstra wrote: > >> This is a collection of x86/percpu changes that I had pending and got reminded >> of by Linus' comment yesterday about __this_cpu_xchg(). >> >> This tidies up the x86/percpu primitives and fixes a bunch of 'fallout'. > > (Sorry; this is going to have _wide_ output) > > OK, so what I did is I build 4 kernels (O=defconfig-build{,1,2,3}) with > resp that many patches of this series applied. > > When I look at just the vmlinux size output: > > $ size defconfig-build*/vmlinux > text data bss dec hex filename > 19540631 5040164 1871944 26452739 193a303 defconfig-build/vmlinux > 19540635 5040164 1871944 26452743 193a307 defconfig-build1/vmlinux > 19540685 5040164 1871944 26452793 193a339 defconfig-build2/vmlinux > 19540685 5040164 1871944 26452793 193a339 defconfig-build3/vmlinux > > Things appear to get slightly larger; however when I look in more > detail using my (newly written compare script, find attached), I get > things like:
Nice script! I keep asking myself how comparing two binaries can provide some “number” to indicate how “good” the binary is (at least relatively to another one) - either during compilation or after. Code size, as you show, is the wrong metric.
Anyhow, I am a little disappointed (and surprised) that in most cases that I played with, this kind of optimizations have marginal impact on performance at best, even when the binary changes “a lot” and when microbenchmarks are used.
| |