Re: [GIT PULL] tracing: Updates for 7.2

[Linus Torvalds]

On Fri, 19 Jun 2026 at 11:30, Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
>
> So if this is just about splitting trace_printk away from kernel.h,
> okay. Even container_of() moved out and is included explicitly which is
> used a lot. If this next so be it.

Absolutely.

We should aim to never have the insanity that is a typical C++ build
system, where you have headers that include the world because of how
the C++ method and object models work.

That way lies insanity. It's not only "random small header changes
rebuild everything", it's also simply "everything is slower because
the compiler has to parse way too much irrelevant garbage".

Now, we're not exactly doing great in this area, I'm afraid. To pick a
random small core kernel file, we have this kind of disgusting
situation:

  $ make kernel/pid.i
  $ wc -c kernel/pid.c kernel/pid.i
    24460 kernel/pid.c
  5271779 kernel/pid.i

ie a relatively tiny sub-1kloc file balloons by a factor of 215x and
becomes 5MB worth of noise to parse for the compiler because of header
inclusion.

And the build cost is pretty much directly related to that kind of
expansion (admittedly linking is bad too, mainly because our linking
phases tend to be more serialized than building most C files)

Now, I picked a small file on purpose and this is with 'allmodconfig'
which makes a bad situation even worse by about 20%. That small file
expands to "only" 4.2MB in a more sedate config.

But even our *biggest* C file in the kernel subdirectory sees a 20x
expansion due to pre-processing.

And yes, <kernel/trace_printk.c> is part of that, but certainly not a
very big part - it's only 6kB and 202 lines in that mess.

A pittance. Hardly noticeable.

But "it's a small part of the problem" doesn't mean that it shouldn't
be fixed when it looks like it's *trivial* to fix.

Now, the biggest single cause of horrible expansion to be some of our
more complex nested macros.  So it's not always about the size of the
header and how many other headers it includes, we have some other
structural issues that make it worse.

We had very real build performance issues due to the deep nesting of
the min/max macros to the point that they even caused build failures
on machines with limited memory.

But we mostly fixed the worst part of that mess, and the type checking
in those macros at least add real value to normal code.

But in general, if the question is "should we split this header file
up if it's straightforward and easy", the answer is *ALWAYS* a
resounding "YES".

Most of the time it's just a pain to unravel all the type
dependencies. This case look strivial compared to some we've done.

One of the things I at one point hoped sparse would do was a "you're
including this header for no good reason" tooling.

But it's non-trivial to do, particularly with lots of different
architectures that aren't very consistent in where they declare or use
things.

                     Linus