Received-SPF: pass (google.com: domain of linux-kernel+bounces-117085-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 25 Mar 2024 15:05:22 +0200
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Max Kellermann <max.kellermann@ionos.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/35] Fast kernel headers: reduce header dependencies
Message-ID: <ZgF2khndC_QTu5Bw@smile.fi.intel.com>
References: <20240209164027.2582906-1-max.kellermann@ionos.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240209164027.2582906-1-max.kellermann@ionos.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Fri, Feb 09, 2024 at 05:39:52PM +0100, Max Kellermann wrote:
> This patch set aims to reduce the dependencies between headers, in
> order to have cleaner code and speed up the build.  It continues
> previous efforts by other developers.
> 
> As a preparation, the first patch adds "#include" directives to source
> files that were missing previously, but due to indirect includes, this
> was never noticed.  After the cleanup, many missing directives would
> result in a compiler failure.
> 
> The second patch removes superfluous "#include" directives, some of
> which may be a leftover from refactoring patches.
> 
> The third patch replaces existing "#include" directives with narrower
> ones, e.g. use "spinlock_types.h" instead of "spinlock.h".  This
> continues the work others have done over the years.
> 
> The remaining patches add new "XXX_types.h" headers with lighter
> dependencies.  They have only basic struct/enum/const/macro
> definitions and maybe a few trivial inline functions, but no "extern"
> functions and no complex header dependencies.
> 
> Just like the other attempts to reduce header dependencies in the
> past, this is just the beginning.  There are still too many
> dependencies, and the speedup gained by this large patch set is not
> yet impressive.
> 
> Prior to this patch set:
> 
>  real	0m34.677s
>  user	23m13.045s
>  sys	2m26.007s
> 
> With this patch set:
> 
>  real	0m34.464s
>  user	22m19.073s
>  sys	2m15.246s
> 
> (Building the directories kernel,lib,mm on ARM64 "allyesconfig".)
> 
> I have tested this patch set with:
> 
> - ARCH=arm allyesconfig
> - ARCH=arm defconfig
> - ARCH=arm64 allyesconfig
> - ARCH=arm64 defconfig
> - ARCH=mips defconfig
> - ARCH=riscv defconfig
> - ARCH=x86_64 allyesconfig
> - ARCH=xtensa defconfig
> 
> Pretty sure, other architectures may fail to build, but before I test
> all of them, I'd like to get some feedback on whether my approach
> would be accepted.
> 
> For more gains, huge headers like "linux/mm.h", "linux/fs.h" and
> "linux/sched.h" would need to be optimized.  Nearly everybody includes
> them, and they include nearly everything.

Are you going to pursue this (with probably refined kernel.h approach
as we have Ingo's patches and an additional split that is already in
the upstream)?

-- 
With Best Regards,
Andy Shevchenko