Use a portable job count for -j in the Arm build docs and notebooks

[ShamSaleem]

Summary

The Arm flow is supported on macOS, but every build command in its docs and notebooks uses -j$(nproc), which does not exist there.

macOS support is not incidental to this flow. The Ethos-U getting-started tutorial states it under Prerequisites — "a Linux machine with aarch64 or x86_64 processor architecture, or a macOS™ machine with Apple® Silicon" — backends/arm/scripts/utils.sh:186 rejects anything but Linux and Darwin on arm64, and backends/arm/scripts/toolchain_utils.sh:31 downloads a darwin-arm64 bare-metal toolchain.

On macOS the documented command loses its -j argument entirely:

$ cmake --build ethos_u_minimal_example -j$(nproc) -- arm_executor_runner
sh: nproc: command not found
# runs as: cmake --build ethos_u_minimal_example -j -- arm_executor_runner

That is a bare -j, so the build runs unbounded rather than at the intended core count.

This replaces those 16 sites with the portable form already established in the tree by #20436:

-j$(( $(nproc 2>/dev/null || sysctl -n hw.ncpu) + 1 ))

Scope is deliberately limited to the Arm flow, where macOS is a documented host. The remaining bare -j$(nproc) sites live in backends with no stated macOS support (QNN, CUDA, Samsung, OpenVINO, Espressif) and are left alone.

Follow-up to #21455, which converted the hardcoded -jN sites; @synath raised this pattern in review there and I said it would be a separate PR. Partial fix for #10887.

The Ethos-U tutorial is generated, so backends/arm/scripts/docgen/ethos-u/ethos-u-getting-started-tutorial.md.in and its output docs/source/backends/arm-ethos-u/tutorials/ethos-u-getting-started.md are both updated; the edited line is in the template's static text, not the $MINIMAL_EXAMPLE substitution, so re-running docgen.py reproduces the committed file.

Test plan

Docs and notebooks only — no build or runtime code changes.

Verified the replacement expression on both branches. With nproc available (16 cores):

$ echo "jobs = $(( $(nproc 2>/dev/null || sysctl -n hw.ncpu) + 1 ))"
jobs = 17

With nproc absent and sysctl -n hw.ncpu reporting 8, as on macOS:

$ env -i PATH="$stub" sh -c 'echo "jobs = $(( $(nproc 2>/dev/null || sysctl -n hw.ncpu) + 1 ))"'
jobs = 9

Confirmed no bare -j$(nproc) remains in the touched files, that the four notebooks still parse as JSON, and that the generated tutorial still matches its template with the placeholder substituted.

This PR was authored with AI assistance (Claude Code).

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22585

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 21 Awaiting Approval

As of commit f621b24 with merge base 5cdcc02 ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build Aarch64 Linux CUDA Wheels (gh)
• Build Aarch64 Linux Wheels (gh)
• Build CMSIS Pack (gh)
• Build documentation (gh)
• Build Linux CUDA Wheels (gh)
• Build Linux Wheels (gh)
• Build macOS Wheels (gh)
• Build Presets (gh)
• Build Windows Wheels (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test Cortex-M Backend (gh)
• Test NXP Backend (gh)
• Test QNN Backend (gh)
• Test QNN Windows MSVC build (gh)
• Test Vulkan Backend (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[pytorch-bot]

The following ciflow label(s) have been added but CI has not been triggered yet because the workflows are awaiting approval:

• ciflow/trunk

Once a maintainer approves the workflows (scroll to the bottom of the PR page), the corresponding CI jobs will be triggered automatically. Please ping one of the reviewers if you do not have access to approve and run workflows.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.