[Intel-gfx] [PATCH 00/12] radix-tree: split out struct radix_tree_root out to <linux/radix-tree-root.h>

[Masahiro Yamada]

2017-10-10 21:18 GMT+09:00 Matthew Wilcox <willy at infradead.org>:
> On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote:
>> Reducing the header dependency will help for speeding the kernel
>> build, suppressing unnecessary recompile of objects during
>> git-bisect'ing, etc.
>
> Well, does it?  You could provide measurements showing before/after
> time to compile, or time to recompile after touching a header file that
> is included by radix-tree.h and not by radix-tree-root.h.
>
> Look at the files included (never mind the transitively included files):
>
> #include <linux/bitops.h>
> #include <linux/bug.h>
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/preempt.h>
> #include <linux/rcupdate.h>
> #include <linux/spinlock.h>
> #include <linux/types.h>
>
> These are not exactly rare files to be included.  My guess is that most
> of the files in the kernel end up depending on these files *anyway*, either
> directly or through some path that isn't the radix tree.


Good question.

I tested this series, and I confirmed
the total number of included headers decreased,
but did not decrease as much as I had expected.

The statement "most of the files in the kernel end
up depending on these files" is true.

But, with that excuse,
I do not want to conclude this kind of refactoring is pointless.


For example, how can we explain
commit bc6245e5efd70c41eaf9334b1b5e646745cb0fb3 ?


<linux/bug.h> includes the following three.

#include <asm/bug.h>
#include <linux/compiler.h>
#include <linux/build_bug.h>

Your statement applies to them too.
Actually, I did not see any impact
by replacing <linux/bug.h> in my files with <linux/build_bug.h>



Generally, people do not pay much attention
in decreasing header dependency.

One refactoring alone does not produce much benefits,
but making continuous efforts will disentangle the knotted threads.
Of course, this might be a pipe dream...



-- 
Best Regards
Masahiro Yamada