Two kernel updates stood out this fortnight. Linux 7.1 was released, and the Linux 7.2 merge window opened. When you read both together, a common theme appears: the mainline kernel is increasing its minimum requirements in three areas at once — the hardware it will still boot, the kernel configuration options it allows, and the compiler version needed to build it. Below is a short index of the items covered, followed by a detailed look at each and what I recommend you do about it.
In this edition
- Linux 7.1 released (14 June) — removes the last i486-era x86 support, and makes two breaking networking configuration changes: UDP-Lite is removed, and IPv6 can no longer be built as a module. (CNX Software)
- Cache-Aware Scheduling merged for the 7.2 window — a new
CONFIG_SCHED_CACHEoption that keeps cooperating tasks on CPUs sharing a last-level cache; increasingly relevant to multi-cache embedded SoCs. (Phoronix) - Higher build toolchain requirement in 7.2 — the minimum LLVM/Clang version rises from 15 to 17, and Distributed ThinLTO support is added. (Phoronix)
Linux 7.1: the removals affect embedded more than the desktop
Linus Torvalds released Linux 7.1 on 14 June. The most reported change is the removal of the last 486-era x86 subarchitectures — the M486, M486SX and ELAN Kconfig options are now gone, as part of a larger cleanup that removed more than 140,000 lines of legacy code, including old PCMCIA host controllers and several unused network drivers. For most teams this is routine maintenance. If you were still running a 1994-era SoC, you were not tracking mainline in any case.
The changes that matter more for embedded work are smaller and sit in the networking stack. Two of them can break an existing configuration:
- UDP-Lite has been removed. The partial-checksum UDP variant always had few users, but those users were mainly in telephony, multimedia transport and some constrained-link IoT stacks — areas where a small number of embedded products depend on it.
- IPv6 can no longer be built as a module.
CONFIG_IPV6must now be set to built-in (=y) or disabled (=n); the=moption has been removed. If your defconfig usedCONFIG_IPV6=m— and many older vendor defconfigs do, to keep the base image small — your build will no longer produce the same result.
This affects embedded teams in particular because desktop distributions ship a single, well-maintained kernel configuration. Embedded teams maintain their own defconfig, often derived from a vendor BSP several kernel versions ago and not fully reconciled since. A breaking configuration change does not always produce a clear build error; make oldconfig drops the now-invalid option and continues without warning. You may only notice when IPv6 is missing on the target, or when a UDP-Lite socket call returns EPROTONOSUPPORT in production. My recommendation is to treat the move to 7.1 as a configuration audit, not a simple version bump. Compare your running configuration against a fresh make defconfig for your architecture, check specifically for IPV6 and UDPLITE, and if you maintain a Yocto or Buildroot layer, set the change explicitly in your .config fragment instead of inheriting it. The rewritten in-kernel NTFS driver in the same release improves throughput on x86 systems but is not relevant to most embedded targets, so it should not divert attention from the configuration audit, which is the part that will affect you.
Cache-Aware Scheduling in 7.2: more relevant to edge silicon than it first appears
The main feature of the newly opened 7.2 merge window is Cache-Aware Scheduling, added after more than a year of work by Intel engineers and controlled by the new CONFIG_SCHED_CACHE option. The principle is straightforward: when several tasks share data, the scheduler tries to keep them on CPUs that share the same last-level cache (LLC), so they access cached data instead of moving it across the interconnect.
It is easy to treat this as a feature only for large EPYC and Xeon servers, since that is where the published benchmarks come from. However, embedded silicon is moving in the same direction. Modern application-class SoCs are no longer flat: an NXP i.MX 95, a Rockchip RK3588, an Arm DynamIQ cluster or an NVIDIA Jetson with a big.LITTLE topology increasingly present multiple cache domains to the scheduler. Once a board has more than one LLC, cache placement has a measurable cost, and a workload of cooperating threads — a video pipeline, a sensor-fusion graph, or a set of IPC-heavy services — is the pattern this feature is designed to help. The same merge also added SMT-aware SD_ASYM_CPUCAPACITY handling and improved cfs_rq/sched_entity data locality, both relevant to the asymmetric big.LITTLE layouts that have been common in embedded systems for years.
My recommendation is to not enable it without testing, and to not assume it will help. Cache-aware placement is a trade-off: grouping cooperating tasks can leave some cores under-used, which may reduce performance for throughput-bound or latency-sensitive real-time workloads. For an embedded product, the correct approach is to measure on your actual board. If you run workloads with strict timing requirements such as PREEMPT_RT, an industrial control loop or an audio path, measure latency percentiles rather than average throughput before using it in production:
# confirm the feature is compiled in
zcat /proc/config.gz | grep SCHED_CACHE
# test the workload with the option off and on, and compare
# tail latency, not only average throughput
A higher toolchain requirement: Clang 17 and Distributed ThinLTO in 7.2
A less visible but possibly more disruptive change for build infrastructure: Linux 7.2 raises the minimum LLVM/Clang requirement from Clang 15 to Clang 17, and adds support for LLVM’s Distributed ThinLTO (DTLTO) mode, which can build the kernel faster than in-process ThinLTO.
If you build with GCC, this does not affect you. If you build with Clang — and a growing number of Android and security-hardened embedded BSPs do, because CFI and several hardening features are Clang-first — then your toolchain now has a hard minimum version. The point to note for embedded work is that the cross-toolchain is usually not the latest version on a developer’s machine; it is fixed by your Yocto release, your vendor SDK, or a shared Docker build image that is often several years old. Moving from Clang 15 to 17 is only about one year of releases, as the maintainers note, but in a reproducible-build environment, changing the pinned cross-compiler is a deliberate, tested step, not something to do shortly before a release. I recommend planning this change in advance rather than encountering it when 7.2 arrives. The Distributed ThinLTO support is a useful improvement: kernel link-time optimization has been demanding on memory and build time in CI, and distributing the work across build nodes is a real productivity gain for teams that build LTO-enabled hardened kernels in a build farm. It is worth evaluating once your toolchain meets the Clang 17 requirement. Building a team’s depth in kernel configuration, the scheduler and the toolchain, so that changes like these can be handled without disruption, is the focus of our Linux kernel and embedded training at TECH VEDA.
References
- Linux 7.1 Release — Main changes, Arm, RISC-V and MIPS architectures (CNX Software)
- Linux 7.1 Released: New NTFS Driver, Intel FRED, code cleanup (Phoronix)
- Cache Aware Scheduling Merged For Linux 7.2 (Phoronix)
- Linux 7.2 scheduler pull request (lore.kernel.org)
- Linux 7.2 To Raise LLVM/Clang Requirement, Add Distributed ThinLTO (Phoronix)
— Raghu Bharadwaj
