Re: [PATCH v4 11/14] perf pmu-events: Parallelize JSON and metric pre-computation in jevents.py

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The use of `ProcessPoolExecutor` without a `max_workers` limit violates GNU Make's jobserver concurrency constraints, causing system oversubscription.
--

commit 09eba7d34c7e309d0f6449fe513b92dfbec5e85c
Author: Ian Rogers <irogers@google.com>

perf pmu-events: Parallelize JSON and metric pre-computation in jevents.py

This commit refactors jevents.py to pre-populate its internal JSON AST cache
in parallel across available CPU cores using ProcessPoolExecutor, reducing
build generation time.

> diff --git a/tools/perf/pmu-events/jevents.py b/tools/perf/pmu-events/jevents.py
> --- a/tools/perf/pmu-events/jevents.py
> +++ b/tools/perf/pmu-events/jevents.py
[ ... ]
> @@ -1459,9 +1471,25 @@ struct pmu_table_entry {
[ ... ]
>    for arch in archs:
>      arch_path = f'{_args.starting_dir}/{arch}'
>      preprocess_arch_std_files(arch_path)
> +    ftw(arch_path, [], collect_json)
> +
> +  with concurrent.futures.ProcessPoolExecutor(initializer=_init_worker, initargs=(_arch_std_events,)) as executor:

Does this bypass GNU Make's jobserver concurrency constraints? By
instantiating ProcessPoolExecutor without a max_workers limit, it will
default to spawning workers for all available CPU cores.

If a user explicitly requests a restricted build with make -j1, or if this
runs alongside numerous other compilation jobs, could it lead to extreme
CPU contention and potential out-of-memory failures?

> +    for path, topic, events in executor.map(_parallel_read_json_events, tasks):
> +      _json_cache[(path, topic)] = events
> +
> +  for arch in archs:
> +    arch_path = f'{_args.starting_dir}/{arch}'
>      ftw(arch_path, [], preprocess_one_file)

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