Messages in this thread | | | Date | Thu, 04 Oct 2018 01:40:20 -0700 | Subject | Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions | From | hpa@zytor ... |
| |
On October 4, 2018 1:33:33 AM PDT, Ingo Molnar <mingo@kernel.org> wrote: > >* Ingo Molnar <mingo@kernel.org> wrote: > >> I'm also somewhat annoyed at the fact that this series carries a >boatload >> of reviewed-by's and acked-by's, yet none of those reviewers found it >> important to point out the large chasm that is gaping between >description >> and reality. > >Another problem I just realized is that we now include >arch/x86/kernel/macros.S in every >translation pass when building the kernel, right? > >But arch/x86/kernel/macros.S expands to a pretty large hiearchy of >header files: > > $ make arch/x86/kernel/macros.s > >$ cat $(grep include arch/x86/kernel/macros.s | cut -d\" -f2 | sort | >uniq) | wc -l > 4128 > >That's 4,100 extra lines of code to be preprocessed for every >translation unit, of >which there are tens of thousands. More if other pieces of code get >macrofied in >this fasion in the future. > >If we assume that a typical distribution kernel build has ~20,000 >translation units >then this change adds 82,560,000 more lines to be preprocessed, just to >work around >a stupid GCC bug? > >I'm totally unhappy about that. Can we do this without adding macros.S? > >It's also a pretty stupidly central file anyway that moves source code >away >from where it's used. > >Thanks, > > Ingo
It's not just for working around a stupid GCC bug, but it also has a huge potential for cleaning up the inline asm in general.
I would like to know if there is an actual number for the build overhead (an actual benchmark); I have asked for that once already. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
| |