From: Daniel Gomez <da.gomez@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>,
Chuck Lever <cel@kernel.org>, Daniel Gomez <da.gomez@kruces.com>,
kdevops@lists.linux.dev
Cc: David Bueso <dave@stgolabs.net>
Subject: Re: [PATCH] build-linux: add workflow for repeated kernel builds
Date: Fri, 19 Sep 2025 10:29:45 +0200 [thread overview]
Message-ID: <b73f5ae9-4ef8-4c51-89df-e1f13e535b79@kernel.org> (raw)
In-Reply-To: <20250919035158.422509-1-mcgrof@kernel.org>
On 19/09/2025 05.51, Luis Chamberlain wrote:
> Add a new workflow that allows building the Linux kernel multiple times
> to measure build time variations and performance. This is useful for
> benchmarking build systems and compiler performance testing.
>
> This goes in with monitoring support so we can do AB testing against
> different filesystems.
>
> Generated-by: Claude AI
> Suggested-by: David Bueso <dave@stgolabs.net>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
>
> Demo of visualization of results:
>
> https://htmlpreview.github.io/?https://github.com/mcgrof/plot-build/blob/main/index.html
This is really interesting and cool work.
However, I'm generally a strong advocate for reusing projects as much as
possible. So this feels like a missed opportunity not to build on existing
projects designed for this purpose (e.g. hyperfine [1]).
Link: https://github.com/sharkdp/hyperfine [1]
It would be helpful to understand the reasoning behind choosing one
approach (reusing something like hyperfine) over another (adding custom ansible
tasks/playbooks...)?
For reference, I put together a quick and hacky example for benchmarking kernel
builds using hyperfine and a simple Makefile, available here:
https://github.com/dkruces/linux-benchmarks/
Report example:
https://github.com/dkruces/linux-benchmarks/blob/automation-make/results/mac1611/REPORT.md
To clarify, I'm not oppose in any form to the work here. It's really great.
Please, merge & push! :)
One think I'd like to see as part of the report is:
* The kernel version
* The kernel configuration. Hopefully, the fragment work allows to have
better control on this. And better when we have SAT support in the kernel
* Toolchain: GCC, LLVM/Clang
* Host info: baremetal/vm, number of cores, memory available, etc.
I've also noticed some inconsistencies between runs, which could be due to
memory behavior, folio migration, fragmentation, and similar factors. To ensure
full confidence when comparing build times, we should rely on reproducible
builds [2].
Link: https://docs.kernel.org/kbuild/reproducible-builds.html#reproducible-builds [2]
FYI, I have reproducible build support patches ready. I'll post them today.
next prev parent reply other threads:[~2025-09-19 8:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-19 3:51 [PATCH] build-linux: add workflow for repeated kernel builds Luis Chamberlain
2025-09-19 8:29 ` Daniel Gomez [this message]
2025-09-19 18:06 ` Luis Chamberlain
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=b73f5ae9-4ef8-4c51-89df-e1f13e535b79@kernel.org \
--to=da.gomez@kernel.org \
--cc=cel@kernel.org \
--cc=da.gomez@kruces.com \
--cc=dave@stgolabs.net \
--cc=kdevops@lists.linux.dev \
--cc=mcgrof@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