From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753455AbdLDKTn (ORCPT ); Mon, 4 Dec 2017 05:19:43 -0500 Received: from mout.web.de ([212.227.15.4]:62561 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752874AbdLDKTl (ORCPT ); Mon, 4 Dec 2017 05:19:41 -0500 Subject: Re: Difficulties for compilation without extra optimisation To: Steven Rostedt , kernel-janitors@vger.kernel.org Cc: linux-kselftest@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Trond Myklebust References: <7f072f78-eef4-6d87-d233-cee71dac5a32@users.sourceforge.net> <1512314250.3673.6.camel@primarydata.com> <20171203162256.4ea0750d@vmware.local.home> <20171204044842.0edbc51b@vmware.local.home> From: SF Markus Elfring Message-ID: <1b850dea-fdea-cc93-65fb-ba5e2082bcb9@users.sourceforge.net> Date: Mon, 4 Dec 2017 11:18:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171204044842.0edbc51b@vmware.local.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:CRs93+aO5TYU6H68NXHxLSnYz/tG/TYrII717pLJyW/lGgN79WB 5dti0IcofZdeJe2yYnykSFUaADzGc6srNcprGmtcPQ8HZgqoEaZB+xfyQ+bjYA0Z+NvEXp+ vHjqPfxcO1e9TlGYhpaDfcgu3unZYPBOWSJFrs3e/1HuaNmToGbfAE2TEPECPMWPZqXY2RO ze1Wljg7Uqikpi46j73KQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZKZfbki5zB0=:dtoiQLyGETcUY08zgmqESZ GN/4CFlqk0mk+DTveqE1kUDXf+OASAu2iG3brJMktFq0zZwjq1Ep1u0vw1HH3PQPFSrBVra38 RBQooNU4+0jShdEKABlW7m0lNEHDR5VmY/ZQ7NTGB3mlblYddEOJDRsm2e4DEqykgWBiEToo/ Ct0+ohQ2MwaXzQ4Cvcw01dpg87aVdVCN9lQqx4rcH0bYpS89QRTD2Bv+envECduYOigrmPgip kk2lekCg4WO+g5jD0csfe8ULtReqcYOFSehJxLfRZIXUspHKTbzTD13/iR4/6f3tDYHKGAIab EZykbWFhbgi0sF3FPFEyH9akQc1RnZprHtDgIjg5CwryBkX9BILzhAvfh9R5qW48GowZ8kump P2j2w1MZh3AGVxk5okRtESXDYhYkG/8NtmXnzGEpW3FOalmDUiwgdX4vE2k3j60hXj30J/Jm3 9ZxWOr5ifFNTYeQzh1X1UJ2dvs3YDnrSPQQeE8iyaEieKUdAlw7MOidlbWJrvLMsNVm5t6mM1 rzyz6tg1SZddgv71Yc2B03lOLLDadxCzQXliVEyMkiMm8wcqZPj/UvdsaLkk/t7rjxPJQE8Jr oV6H20mpodzZiI7HyybXS1k2FGV59AKTi+XzXLkdSPcYzFmaFJ7Ak4XhyeQyIiokvEERYkYuw anJZAq2jZz18VJJ5bwUOT9kwRYHLXh7SQdc9sjvjXEmi3C2Pli9hNBQi7d9Tovbq+jBCri+Em posjb8SxoRTjNedtBgNlhfyX/iZK6vp44IgAgg3tOoobvvyvM/ho5EOnbIlaeski+AaWcOf1Y Ttg/NkoWPFdn/+BxYn+3mInYV3o7N3kv728RwwVUx0EKuOnFex4B7mL36zMeMswaOPKn/tY Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> Will the compilation be a bit quicker when extra data processing >> could be omitted? > > Why would you care more about the time it takes to compile the kernel, > than the time it takes for executing it? I am also interested in the evolution of compilation time frames. > Benchmarks are all about performance of a running kernel, This is generally reasonable. > nobody compares benchmarks of the time it takes to compile it. I guess that the situation can be occasionally different there. > Sure, we like to make the compile times quicker Good to know … > (heck, I wrote "make localmodconfig" for just that purpose), Thanks. > but we never favor compiler time over execution time. I imagine that the speed expectations could be adjusted during software development, couldn't they? > In fact, if we can improve the execution performance by sacrificing compile time, > we are happy to do that. I guess that you would like to consider some constraints there. >>> In fact, we do a lot of tricks to make sure that things work the way >>> we expect it to, because we add broken code that only gets compiled out >>> when gcc optimizes the code the way we expect it to be, >>> and the kernel build will break otherwise. >> >> * Can this goal be also achieved without the addition of “broken code”? > > No. Will any other contributors take another look? >> * How do you think about to improve the error handling there? > > It works just fine as is. I hope that further software improvements can be achieved also for this use case. > Errors that can be detected at build time are 100 times better > than detecting them at execution time. I agree to such a general view. Will an other (or no) error message be more appropriate? Regards, Markus