Re: [PATCH v5 01/11] kbuild: calculate list, composite object state per object

[Nathan Chancellor]

> When each object's command line is expanded, kbuild has to figure out on
> multiple occasions whether it's built-in or part of a module and which
> composite object it belongs to.
> 
> This causes the time spent on each directory in the kernel tree to grow
> O(n^2) with its object count, which is especially problematic for instance
> in drivers/gpu/drm/amd/amdgpu with 310 objects.
> 
> No-op builds (i.e. make -j $(nproc) when nothing has changed) are
> particularly impacted by this.
> 
> Fix the issue by calculating this data once and looking it up thereafter
> instead of recomputing it over and over again.
> 
> This has a particularly large impact on allmodconfig builds.
> 
> Whole build, 128-thread Threadripper 9980X, best of N runs:
> 
>                                          before   after     delta
>                                          -------------------------------
>   x86 defconfig, no-op make, gcc            1.1s     1.1s    -0.02s (-2%)
>   x86 defconfig, no-op make, clang          1.3s     1.3s    -0.01s (-1%)
>   x86 allmodconfig, no-op make, gcc        15.3s    14.5s    -0.83s (-5%)
>   x86 allmodconfig, no-op make, clang      16.2s    15.5s    -0.65s (-4%)
>   x86 allmodconfig, touch mm/vma.c, gcc    35.0s    34.3s    -0.77s (-2%)
>   x86 allmodconfig, touch mm/vma.c, clang  33.7s    33.2s    -0.51s (-2%)
> 
> Reviewed-by: Nicolas Schier <n.schier@xxxxxxxxx>
> Reviewed-by: Kees Cook <kees@xxxxxxxxxx>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>

Seems like a nice win.

Reviewed-by: Nathan Chancellor <nathan@xxxxxxxxxx>

-- 
Cheers,
Nathan