All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v3] perf tests: Improvements to build-test performance
Date: Wed, 09 Sep 2026 16:21:18 +0000	[thread overview]
Message-ID: <20260909162119.3C3B51F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260909161041.1745638-1-irogers@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The parallelization of the `out` target causes destructive races between `FEATURES_DUMP_FILE` and `FEATURES_DUMP_FILE_STATIC` within the shared source tree.
--

commit 8a5611d5732e412e746570eca199bea2894c319b
Author: Ian Rogers <irogers@google.com>

perf tests: Improvements to build-test performance

This patch replaces hardcoded 'make' calls with '$(MAKE)' in the perf tests
Makefile to ensure proper GNU Make jobserver file descriptor inheritance. It
also removes 'unexport MAKEFLAGS' in favor of native GNU Make conditionals
for parallelism. Finally, it optimizes the 'out' target by wrapping the target
list in a parallel sub-make call.

> diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> index d2c2f526e1db0..4a865e58f2bea 100644
> --- a/tools/perf/tests/make
> +++ b/tools/perf/tests/make
[ ... ]
> @@ -383,20 +391,22 @@ all: $(run) $(run_O) tarpkg make_kernelsrc make_kernelsrc_tools
>  	@echo OK
>  	@rm -f $(FEATURES_DUMP_FILE) $(FEATURES_DUMP_FILE_STATIC)
>  
> -out: $(run_O)
> +out:
> +	$(call clean)
> +	@$(MAKE) -f tests/make $(run_O) PARALLEL_OPT= O_CLEAN=0 $(if $(findstring jobserver,$(MAKEFLAGS))$(findstring -j,$(MAKEFLAGS)),,$(if $(cores),-j$(cores)))

[Severity: Medium]
When the out target invokes this parallel sub-make for all run_O targets, does
this expose the feature dump dependencies to concurrent evaluation?

>  	@echo OK
>  	@rm -f $(FEATURES_DUMP_FILE) $(FEATURES_DUMP_FILE_STATIC)
>  
>  ifeq ($(REUSE_FEATURES_DUMP),1)
>  $(FEATURES_DUMP_FILE):
>  	$(call clean)
> -	@cmd="cd $(PERF) && make FEATURE_DUMP_COPY=$@ $(O_OPT) feature-dump"; \
> +	@cmd="cd $(PERF) && $(MAKE) FEATURE_DUMP_COPY=$@ $(O_OPT) feature-dump"; \
>  	echo "- $@: $$cmd" && echo $$cmd && \
>  	( eval $$cmd ) > /dev/null 2>&1
>  
>  $(FEATURES_DUMP_FILE_STATIC):
>  	$(call clean)
> -	@cmd="cd $(PERF) && make FEATURE_DUMP_COPY=$@ $(O_OPT) LDFLAGS='-static' feature-dump"; \
> +	@cmd="cd $(PERF) && $(MAKE) FEATURE_DUMP_COPY=$@ $(O_OPT) LDFLAGS='-static' feature-dump"; \

[Severity: Medium]
Will these feature dump recipes race destructively?

Since some run_O targets like make_static_O depend on
FEATURES_DUMP_FILE_STATIC while others depend on FEATURES_DUMP_FILE,
evaluating them concurrently means both unconditionally invoke make clean and
make feature-dump inside the shared source tree.

Could this cause them to wipe out each other's intermediate artifacts during
make build-test out-of-tree builds?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909161041.1745638-1-irogers@google.com?part=1

  reply	other threads:[~2026-09-09 16:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 15:31 [PATCH v1] perf tests: Improvements to build-test performance Ian Rogers
2026-09-02 15:40 ` sashiko-bot
2026-09-03  4:56 ` [PATCH v2] " Ian Rogers
2026-09-03  5:04   ` sashiko-bot
2026-09-09 16:10   ` [PATCH v3] " Ian Rogers
2026-09-09 16:21     ` sashiko-bot [this message]
2026-09-09 17:38       ` Ian Rogers

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=20260909162119.3C3B51F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.