Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Miguel Ojeda <ojeda@kernel.org>
Cc: linux-man@vger.kernel.org, Nathan Chancellor <nathan@kernel.org>,
	 Nicolas Schier <nsc@kernel.org>,
	linux-kbuild@vger.kernel.org
Subject: Non-recursive makefiles, and static pattern rules
Date: Wed, 7 Oct 2026 22:07:41 +0200	[thread overview]
Message-ID: <asai2yXbMC1KJ-ty@debian> (raw)

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

Hi Miguel,


As we talked earlier today, if you're trying to improve performance of
the kernel makefiles, I recommend checking a few things we've done in
the man-pages.git repo.

In the man-pages, we have a huge set of makefiles (not as large as the
kernel, but 120k is already huge for the scale of this project).  The
performance seems nice, and it's a non-recursive set of makefiles.

(If you're curious, the reason we have so much makefile code is that
 I set up a large number of linters to run in the build system, with
 'make -R lint'.  See 'make -R help' and 'make -R help-targets' if you
 want to look at what we have available there.)

We use static pattern rules:
<https://www.gnu.org/software/make/manual/html_node/Static-Pattern.html>

That is:

	targets …: target-pattern: prereq-patterns …
		recipe
		…

This results in a huge database when make(1) runs, being 10x larger than
what we would get with regular pattern rules.

However, recently I tried moving to pattern rules, since I thought the
smaller database could improve performace, but the experience was
surprising: the run time degraded by several orders of magnitude.
I don't remember the exact numbers, but a full
	'make -R -j24 build-all lint check'
(which is building almost everything that the build system can build)
would take a few minutes with the huge database, and several hours with
the size-optimized database using regular pattern rules.

I suspect it's because by having to guess for each file which rule to
apply (and being non-recursive, it has the whole list of thousands of
files, and around a hundred different patterns, so the combination is
explosive) is too expensive.  By using pattern rules, make(1) doens't
have to guess, and thus goes directly to the rule that applies to each
file.

I think this might solve the issues you were seeing in your experiment.
(Or it might not.)  :-)

Please let me know if this changes anything in your experiments!


Have a lovely night!
Alex


-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2026-10-07 20:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 20:07 Alejandro Colomar [this message]
2026-10-07 20:11 ` Non-recursive makefiles, and static pattern rules Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=asai2yXbMC1KJ-ty@debian \
    --to=alx@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=ojeda@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox