Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros

[Nadav Amit <namit@vmware.com>]

From: Nadav Amit
Sent: November 13, 2018 at 5:55:34 PM GMT
> To: Ingo Molnar <mingo@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>, Masahiro Yamada <yamada.masahiro@socionext.com>, Michal Marek <michal.lkml@markovi.net>, Thomas Gleixner <tglx@linutronix.de>, Borislav Petkov <bp@alien8.de>, H. Peter Anvin <hpa@zytor.com>, X86 ML <x86@kernel.org>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Logan Gunthorpe <logang@deltatee.com>
> Subject: Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros
> 
> 
> From: Ingo Molnar
> Sent: November 13, 2018 at 11:30:00 AM GMT
>> To: Nadav Amit <namit@vmware.com>
>> Cc: Ingo Molnar <mingo@redhat.com>, Masahiro Yamada <yamada.masahiro@socionext.com>, Michal Marek <michal.lkml@markovi.net>, Thomas Gleixner <tglx@linutronix.de>, Borislav Petkov <bp@alien8.de>, H. Peter Anvin <hpa@zytor.com>, x86@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros
>> 
>> 
>> 
>> * Nadav Amit <namit@vmware.com> wrote:
>> 
>>> Introducing the use of asm macros in c-code broke distcc, since it only
>>> sends the preprocessed source file. The solution is to break the
>>> compilation into two separate phases of compilation and assembly, and
>>> between the two concatanate the assembly macros and the compiled (yet
>> 
>> s/concatenate
>> 
>>> not assembled) source file. Since this is less efficient, this
>>> compilation mode is only used when make is called with the "DISTCC=y"
>>> parameter.
>>> 
>>> Note that the assembly stage should also be distributed, if distcc is
>>> configured using "CFLAGS=-DENABLE_REMOTE_ASSEMBLE".
>> 
>> It's a bit sad that we regressed distcc performance …
> 
> I don’t know what the actual impact is, but Logan, who reported the bug says
> there is an alternative solution for when distcc-pump is used (which
> presumably would have ~zero performance degradation). distcc is really
> fragile IMHO - it’s enough that it finds what looks like two source files in
> the compiler command arguments for it to fall back to local compilation.
> 
> [ In this regard, the distcc-pump solution would *not* work if distcc is
> built with support for distributed assembly, since it will consider the .s
> file as a second source file. ]
> 
>>> +# If distcc is used, then when an assembly macro files is needed, the
>>> +# compilation stage and the assembly stage need to be separated. Providing
>>> +# "DISTCC=y" option enables the separate compilation and assembly.
>> 
>> Let's fix the various typos:
>> 
>>> +# If distcc is used, and when assembly macro files are needed, the
>>> +# compilation stage and the assembly stage needs to be separated. 
>>> +# Providing the "DISTCC=y" option enables separate compilation and 
>>> +# assembly.
> 
> That’s grammar, not typos ;-)
> 
> Sorry for that - I will fix it an send v2 (as well as the whitespace noise).

Just one question before I send v2, since I have second thoughts. Does it
make sense to require the “DISTCC” make parameter, or should it be set in
the Kconfig? It can be detected automatically, the same way gcc/clang are
detected or manually through a config option.