Kernel & Embedded News: Arm64 Drops Big-Endian, Boots CPUs in Parallel

The theme this week is direction-setting on arm64. Two of the five items come from the arm64 maintainer’s own queue, posted on the same day, and both change what the platform will look like for the next decade: one removes a capability, the other modernises how arm64 machines with PSCI firmware boot. The remaining items cover the 7.3 stabilisation cycle, the embedded build-system cadence, and the infrastructure your git workflows depend on.

In this edition

• Arm64 big-endian removal queued for Linux 7.4. Will Deacon’s 14-patch v2 deletes the remaining big-endian kernel code; four maintainer acks are already in. — planning signal
• Parallel CPU onlining through PSCI proposed for arm64. A 19-patch series wires arm64 into the generic HOTPLUG_PARALLEL machinery, with measured bringup-time cuts of 41 to 65 percent on the predecessor series. — long-term watch
• Linux 7.3-rc2 is unusually large. The quiet week after the merge window did not happen; scheduler fixes for cache-aware load balancing on hybrid CPUs lead the pull. — test now
• Buildroot 2026.08 released. Close to 1,000 changes: Linux 7.1.x headers, GCC 16.2.0 available, glibc 2.44, M68K nommu and IBM Power 10/11 support. — evaluate the upgrade
• AI crawlers take a fifth of git.kernel.org capacity. First-party numbers from the kernel.org administrator: roughly 6 million daily requests, and only about 2 percent of traffic is legitimate. — workflow signal

Arm64 prepares to remove big-endian support

Will Deacon posted version two of “arm64: Remove unused big-endian support” on 7 September: 14 patches deleting roughly 540 lines of big-endian handling from the arm64 tree. The BPF JIT, the crypto assembly, the optimised string routines, the compat vDSO build, and the KVM hypervisor object all lose their big-endian paths, and every use of CONFIG_CPU_BIG_ENDIAN and __AARCH64EB__ under arch/arm64 goes away. The v2 series is rebased onto 7.3-rc1 and now forces little-endian explicitly during early boot.

This is the end of a staged process, not a sudden decision. CPU_BIG_ENDIAN was made to depend on BROKEN in 6.18, which made the code unbuildable in practice, and pieces of dead big-endian support have been leaving the tree since. The removal is planned for the 7.4 merge window, and the series already carries acks from Catalin Marinas, Arnd Bergmann, Eric Biggers and Marc Zyngier.

Two details matter for embedded teams. First, SETEND emulation for 32-bit user tasks stays, so mixed-endian 32-bit userspace continues to run. Second, in the review thread Arnd Bergmann confirmed the same process on 32-bit Arm: big-endian mode there is marked deprecated in 7.3, the ixp4xx platform has been repaired to run little-endian, and the arm32 removal is expected to wait one more long-term release.

We covered the pattern this belongs to in our 32-bit Arm deprecations edition: the kernel is systematically shedding configurations that have no testers. Big-endian arm64 hardware exists mostly in networking and telecom appliances built on vendor kernels; mainline effectively never had a big-endian arm64 user base, and code nobody boots is code nobody notices breaking.

How to check your device

A product that needs a big-endian arm64 kernel now has a fixed upper bound: kernel 7.3 and its stable series, and nothing after that. Check what you are actually running before assuming this does not affect you, because the configuration hides inside some vendor BSPs for network processors:

root@${MACHINE}:~# zcat /proc/config.gz | grep CPU_BIG_ENDIAN
# CONFIG_CPU_BIG_ENDIAN is not set

If that symbol is set on any of your targets, start the migration conversation with your silicon vendor now. The realistic paths are a little-endian port of the byte-order-sensitive code, or staying on a frozen kernel with a defined support end. For everyone else, this is a simplification: less conditional assembly in hot paths and one less configuration axis in the architecture you almost certainly ship.

Parallel CPU onlining through PSCI

The same day, Will Deacon posted “arm64: Implement parallel CPU onlining with PSCI v0.2+”, a 19-patch series that lets arm64 bring its secondary CPUs into the kernel concurrently instead of strictly one after another. x86, MIPS and RISC-V already have parallel bringup; arm64 has been a holdout. The series supersedes the HOTPLUG_PARALLEL work posted by Jinjie Ruan of Huawei in June, and the cover letter credits his cooperation in reshaping it.

The mechanism is worth understanding. PSCI v0.2 gave the CPU_ON call a context argument that the firmware hands to the incoming CPU. The series uses it to pass each secondary CPU its boot parameters directly through firmware, which removes the serialisation point where every CPU had to identify itself against shared global state. With that in place, arm64 can drop its own custom secondary-CPU synchronisation and adopt the generic HOTPLUG_PARALLEL, HOTPLUG_SPLIT_STARTUP and core-sync machinery that the other architectures already use. The final patch hardens bringup against broken PSCI firmware, which is a realistic concern on shipping boards.

The performance claim comes from the predecessor series: Jinjie Ruan measured a 192-core HiSilicon server booting its CPUs in 8.6 seconds instead of 14.6, a 41 percent cut, with 62 to 65 percent cuts on 32-core and 64-core boards. There is a third benefit beyond code health and speed: inside a confidential guest, the new scheme protects against a malicious hypervisor that injects secondary CPUs into the guest after the onlining window has closed. Deacon presented the design at last year’s KVM Forum, and the series is based on 7.3-rc2, so the earliest realistic merge target is 7.4.

What it means for product teams

CPU onlining is a visible slice of the boot budget on anything with many cores, and it lands entirely inside the window that fast-boot products care about: cold boot to service, and the reboot window during an A/B update. If your product has a boot-time requirement, put this series on the watch list and measure your current bringup phase — dmesg timestamps around the secondary CPU boot messages give you the number directly. Expect the gain to scale with core count, and expect the new path to stress PSCI implementations in vendor firmware that were only ever exercised serially. If you maintain a TF-A port, testing this series against it before it merges is exactly the kind of early report the arm64 maintainers are asking for.

7.3-rc2: the quiet week that was not

Linus Torvalds released 7.3-rc2 on 6 September and noted that rc2 is normally the calmest point of the cycle, whereas this one was, in his words, a “full fat” rc release. He added that nothing in it looks particularly odd, joking that everyone will blame AI for the volume either way. The fixes span filesystems, networking, BPF, a large DRM pull, and the EDAC updates that were forgotten during the merge window and pulled now. As covered in our 7.3-rc1 edition, this cycle merged the second-busiest merge window on record, so a large volume of fixes was predictable.

The scheduler pull is the part worth reading. 7.3 merged the flattened-runqueue rework of the fair scheduler’s pick path; cache-aware load balancing, which groups related tasks onto cores sharing a last-level cache, has been in the kernel since 7.2. rc2’s scheduler pull carries corrections in this area, and the notable one is from Intel engineer Tim Chen: cache-aware balancing could pull a task toward its preferred cache domain on a hybrid CPU even when the destination cores were too small for it, converting a cache-locality gain into a capacity loss. The fix vetoes such migrations on asymmetric systems, through both can_migrate_llc_task() and the active-balance path, and prioritises misfit migration over cache aggregation when the two conflict.

How to use it

The asymmetric-CPU corrections apply directly to big.LITTLE and DynamIQ embedded silicon, not only to desktop hybrid parts. If your workloads pin latency-sensitive threads on big cores and let the rest float, rc kernels are the right time to run your latency and throughput benchmarks and report regressions — after release, a scheduler behaviour change becomes your problem to bisect. Treat scheduler behaviour on 7.3 as unsettled until late in the rc series, and do not rely on scheduler benchmarks published against rc1 or rc2.

Buildroot 2026.08: the toolchain moves forward

Peter Korsgaard released Buildroot 2026.08 on 4 September, with close to 1,000 changes from 100 contributors. The toolchain updates are the most significant part in practice: support for Linux 7.1.x kernel headers, Binutils 2.46.1, GCC 16.2.0 available with the default moving to GCC 15, glibc 2.44, and uClibc-ng 1.0.59. Architecture support widens with M68K nommu and IBM Power 10/11 variants, and the release adds infrastructure for packages written in the Hare language, a virtual package for libudev, and SDL3 packages. On the removals side, defconfigs for the Acmesystems Aria and Arietta G25, Avnet S6LX9 MicroBoard, and Technologic TS-4900 and TS-5500 boards are gone.

The support arithmetic matters more than any single feature. 2026.08 receives fixes only until 2026.11.1 appears, which is roughly three months. Production products should either track every release deliberately or sit on the 2025.02.x LTS series, which is supported until March 2028. The compiler default moving to GCC 15, with GCC 16.2.0 selectable, is the kind of change to absorb in a controlled rebuild rather than during an unrelated bump — new compiler releases routinely surface latent warnings and subtle miscompilation reports in embedded code that has never seen them.

If you are following our Buildroot series, this release is a good live exercise: a BR2_EXTERNAL tree isolates your packages and board configs, so rebasing from 2026.05 to 2026.08 becomes a contained, testable step instead of a fork migration.

How to evaluate the upgrade

Rebuild your full image against 2026.08 in CI before committing to it. Read the CHANGES file specifically for your package set, confirm none of your boards depended on the removed defconfigs, and decide the GCC question explicitly — staying on the default GCC 15 or opting into 16.2.0 — rather than inheriting it. Teams on 2025.02.x LTS need no action beyond noting that the Buildroot Developers Meeting after ELCE in Prague is where the next LTS’s direction gets discussed.

AI crawlers now cost git.kernel.org a fifth of its capacity

Konstantin Ryabitsev, who runs kernel.org’s infrastructure, published first-party measurements of what AI scrapers cost the project. git.kernel.org receives about 6 million requests per day asking for individual commits rendered as web pages. The Anubis proof-of-work challenge stops 66 percent of them, but a third now solve the challenge and get through. With generous assumptions, legitimate use is about 2 percent of total traffic. Across the five geo-distributed nodes, 14 to 16 of 90 CPU cores do nothing but render commits as HTML for scrapers — around 20 percent of capacity on average, arriving in waves rather than as a steady load.

The detail that should annoy every engineer is the method. All of this data is available through a single git clone, in a form built for exactly this purpose: linux.git holds about 1.48 million commits, and even the mailing-list archives are clonable git repositories. Instead, the crawlers walk the web interface commit by commit — across roughly 922 forks of linux.git that mostly contain identical objects — through millions of short-lived residential and mobile proxy connections that defeat IP-based blocking. The consequence reaches you directly: kernel.org is reducing crawlable URLs and will gate expensive operations, so anonymous web access loses functionality. The data itself stays available to anyone who clones.

What it means for your workflow

Take this as the reason to make your own tooling both well-behaved and self-sufficient. Run an internal mirror for anything CI touches, and never point parallel CI jobs at kernel.org directly — the post singles out simultaneous shallow clones from many nodes as the load pattern that actually takes the service down. If any internal script fetches commits over the cgit web interface one URL at a time, convert it to operate on a local clone. Expect proof-of-work interstitials and reduced anonymous features on kernel.org web properties to become the norm, and budget a few seconds of challenge time into anything interactive.

References

• arm64: Remove unused big-endian support, v2 (7 September 2026)
• arm64: Remove unused big-endian support, v1 and review thread (11 August 2026)
• arm64: Implement parallel CPU onlining with PSCI v0.2+ (7 September 2026)
• arm64: Add HOTPLUG_PARALLEL support for secondary CPUs, v3 (24 June 2026)
• KVM Forum talk on arm64 parallel CPU bringup
• Kernel prepatch 7.3-rc2
• Scheduler fixes pull request for 7.3-rc2
• Linux 7.3-rc2 scheduler fix for cache-aware scheduling misfits
• Buildroot 2026.08 release announcement
• Creepy crawlies — AI crawler measurements on git.kernel.org

— Raghu Bharadwaj