Kernel 7.0 will ship soon and will apparently be the basis of Ubuntu 26.04 and Fedora 44. I assume the same is true for the next Azure Linux. I'd suggest that we dedicate some machines to Ubuntu 26.04. It may be a bit rough at first, but we'll be ready when its real.
Apparent timing:
- Kernel 7.0 GA: April 12 or April 19 (depending on rc7 vs rc8)
- Fedora 44 GA: April 14 — ships before 7.0 stable if rc8 is needed
- Ubuntu 26.04 GA: April 23 — just catches 7.0 if it's April 12 or 19
More context:
Our best way to help the community is to stay ahead of them.
The rest is a Claude-provided analysis, per my request.
--
High Impact Changes
Scheduler / mm/cid performance regression fix
A performance regression in the memory management context ID mechanism, present since Linux 6.19, was resolved in rc4. The fix replaces slow counting logic with more efficient structures for associating CIDs and CPUs. Linus flagged this explicitly as relevant to large servers and high-process-density systems — exactly the profile of .NET workloads under load. This is the highest-priority test target in 7.0: run thread pool scaling, high-concurrency ASP.NET Core, and GC stress benchmarks across 6.18 LTS, 6.19, and 7.0 to isolate both the regression and the fix. Any anomalies your team observed on 6.19 should be re-examined with this fix in mind.
AccECN enabled by default for all TCP
Linux 7.0 is the first kernel to ship with Accurate Explicit Congestion Notification active by default for all TCP connections. This is a networking stack behavior change, not just a new feature — it affects every TCP connection on every workload without opt-in. The expected effect is positive (better congestion signaling, reduced retransmits under load), but "on by default" changes have a history of surprise interactions under high concurrency or specific connection patterns. Run HttpClient throughput, ASP.NET Core request latency, and gRPC benchmarks under realistic load profiles. Compare against a 6.19 baseline with and without manual AccECN enablement to confirm behavior is consistent with expectations.
ARM64 / Cobalt 100: MTE overhead reduction and MIDR errata coverage
The ARM64 pull for Linux 7.0 includes reduced Memory Tagging Extension overhead on AmpereOne, with 25–50% improvement measured for memcached workloads — relevant as a signal for MTE-adjacent code paths on Neoverse N2 class hardware. For Cobalt 100 specifically, the kernel MIDR situation is now clear: MIDR_MICROSOFT_AZURE_COBALT_100 is defined in mainline cputype.h and subscribed to three errata in cpu_errata.c — ARM64_ERRATUM_2067961, ARM64_ERRATUM_2253138, and erratum 3194386 (the speculative SSBS workaround, landed 6.12). The original RFC to override the MIDR was rejected — Marc Zyngier NAK'd blind ID register overriding and directed the submitter to patch individual projects instead. This means the 20–25% performance regression cited in that RFC was caused by userspace libraries (glibc, OpenSSL, etc.) not recognizing the Microsoft implementer ID 0x6D and falling back to slower code paths. Kernel errata coverage is solid as of 6.12, but userspace MIDR-gated optimizations are a separate open question. The dotnet/runtime .NET 10 ARM64 tracking issue explicitly called out Cobalt 100 PAC-RET support, and the .NET 11 ARM64 issue continues SVE2 and NEON GC work. Run your full benchmark suite on Cobalt 100 and verify whether any MIDR-checking userspace libraries your runtime depends on have received Cobalt 100 awareness — otherwise you may be benchmarking against a silently degraded path.
Medium Impact Changes
Intel Nova Lake / Diamond Rapids and AMD Zen 6 enablement
Linux 7.0 includes enablement work for Intel's next-generation server CPUs (Nova Lake, Diamond Rapids) and AMD Zen 6. This includes Intel TSX moving to auto-tune mode on newer Intel CPUs and DSA 3.0 accelerator support for offloading tasks to dedicated silicon on newer Xeons. If your lab has access to any Zen 6 or Diamond Rapids hardware, this is the release to establish your performance baseline on those platforms. JIT-compiled and AOT workloads are particularly worth profiling, as TSX auto-tuning can shift transactional memory behavior in ways that affect lock-heavy code paths in the runtime.
Rust officially stable in the kernel
The "Rust experiment" is formally concluded — Miguel Ojeda's patch marking Rust as no longer experimental landed in the 7.0 merge window. This is structurally significant for the kernel's trajectory: expect more subsystems to introduce Rust-authored drivers and components in subsequent releases. The direct performance impact in 7.0 is minimal, but it signals that memory-safety-motivated rewrites of kernel subsystems are now an ongoing concern rather than a speculative one. Worth noting in the context of your team's own memory safety work — the kernel and .NET are heading in the same direction.
XFS self-healing and filesystem improvements
7.0 includes meaningful XFS improvements. If any of your CI infrastructure, test machines, or container hosts run XFS, run I/O-bound benchmarks: NuGet restore, dotnet build, assembly loading, and ReadyToRun image generation. These workloads are sensitive to filesystem metadata performance and are good at surfacing regressions that don't appear in synthetic I/O benchmarks.
ARM64 LS64/LS64V 64-byte single-copy atomics
The ARM64 7.0 pull wires up 64-byte single-copy atomic load/store instructions (FEAT_LS64, FEAT_LS64V from Armv8.7), now exposed to userspace via /proc/cpuinfo and hardware capabilities. Less immediately actionable for the runtime today, but relevant to AI enablement work — this is the primitive that ML inference runtimes and hardware-adjacent code can exploit for zero-copy data movement into accelerators. SVE vector length correctness on Cobalt 100 is also tracked in dotnet/runtime #101433, which notes that the JIT hardcodes 128-bit assumptions that should instead use the machine's current vector length.
For Your Consideration
Baseline strategy matters more than usual this cycle
The mm/cid regression was introduced in 6.19 and fixed in 7.0-rc4, which means the 6.19 baseline is itself impaired for certain workloads. Establish three comparison points — 6.18 LTS (clean reference), 6.19 (to characterize the regression), and 7.0 (to confirm the fix) — rather than just comparing 7.0 to the most recent stable kernel. Without the 6.18 baseline, it's easy to misread the 7.0 improvement as a kernel gain when it's actually a 6.19 regression being resolved.
Ubuntu 26.04.1 is the real production target, not .0
Canonical confirmed that Ubuntu 26.04 may ship with a 7.0 RC and push the stable kernel via a Day-0 SRU. The 26.04.1 point release in August is when the LTS→LTS upgrade path opens and when most production .NET deployments will actually move. Testing now against 7.0 RCs is valuable for catching regressions early, but your definitive performance baseline for customer-facing guidance should be established against 26.04.1 when it ships.
Fedora 44 will likely ship with 6.19, not 7.0
The F44 beta shipped with kernel 6.19.2 and the final release targets April 14 — potentially before 7.0 stable lands on April 12 or 19. Fedora will pick up 7.0 via post-release updates quickly given its rolling-update philosophy, but don't assume F44 at launch is a 7.0 test environment. Plan to update the kernel explicitly after F44 GA rather than relying on the initial ISO.
Linus is watching the RC cycle size
rc2, rc3, and rc4 have all run above historical averages for their stage in the cycle. Linus attributed this partly to developer psychology around the new major version number, but by rc4 he revised his theory. If rc5 (due ~March 22) continues the trend, the probability of an rc8 and an April 19 GA increases — which tightens the window for both Fedora 44 and Ubuntu 26.04 to ship with a stable 7.0 kernel. Keep an eye on the rc5 LKML announcement when it drops this Sunday.
Kernel 7.0 will ship soon and will apparently be the basis of Ubuntu 26.04 and Fedora 44. I assume the same is true for the next Azure Linux. I'd suggest that we dedicate some machines to Ubuntu 26.04. It may be a bit rough at first, but we'll be ready when its real.
Apparent timing:
More context:
Our best way to help the community is to stay ahead of them.
The rest is a Claude-provided analysis, per my request.
--
High Impact Changes
Scheduler / mm/cid performance regression fix
A performance regression in the memory management context ID mechanism, present since Linux 6.19, was resolved in rc4. The fix replaces slow counting logic with more efficient structures for associating CIDs and CPUs. Linus flagged this explicitly as relevant to large servers and high-process-density systems — exactly the profile of .NET workloads under load. This is the highest-priority test target in 7.0: run thread pool scaling, high-concurrency ASP.NET Core, and GC stress benchmarks across 6.18 LTS, 6.19, and 7.0 to isolate both the regression and the fix. Any anomalies your team observed on 6.19 should be re-examined with this fix in mind.
AccECN enabled by default for all TCP
Linux 7.0 is the first kernel to ship with Accurate Explicit Congestion Notification active by default for all TCP connections. This is a networking stack behavior change, not just a new feature — it affects every TCP connection on every workload without opt-in. The expected effect is positive (better congestion signaling, reduced retransmits under load), but "on by default" changes have a history of surprise interactions under high concurrency or specific connection patterns. Run
HttpClientthroughput, ASP.NET Core request latency, and gRPC benchmarks under realistic load profiles. Compare against a 6.19 baseline with and without manual AccECN enablement to confirm behavior is consistent with expectations.ARM64 / Cobalt 100: MTE overhead reduction and MIDR errata coverage
The ARM64 pull for Linux 7.0 includes reduced Memory Tagging Extension overhead on AmpereOne, with 25–50% improvement measured for memcached workloads — relevant as a signal for MTE-adjacent code paths on Neoverse N2 class hardware. For Cobalt 100 specifically, the kernel MIDR situation is now clear:
MIDR_MICROSOFT_AZURE_COBALT_100is defined in mainline cputype.h and subscribed to three errata in cpu_errata.c —ARM64_ERRATUM_2067961,ARM64_ERRATUM_2253138, and erratum 3194386 (the speculative SSBS workaround, landed 6.12). The original RFC to override the MIDR was rejected — Marc Zyngier NAK'd blind ID register overriding and directed the submitter to patch individual projects instead. This means the 20–25% performance regression cited in that RFC was caused by userspace libraries (glibc, OpenSSL, etc.) not recognizing the Microsoft implementer ID0x6Dand falling back to slower code paths. Kernel errata coverage is solid as of 6.12, but userspace MIDR-gated optimizations are a separate open question. The dotnet/runtime .NET 10 ARM64 tracking issue explicitly called out Cobalt 100 PAC-RET support, and the .NET 11 ARM64 issue continues SVE2 and NEON GC work. Run your full benchmark suite on Cobalt 100 and verify whether any MIDR-checking userspace libraries your runtime depends on have received Cobalt 100 awareness — otherwise you may be benchmarking against a silently degraded path.Medium Impact Changes
Intel Nova Lake / Diamond Rapids and AMD Zen 6 enablement
Linux 7.0 includes enablement work for Intel's next-generation server CPUs (Nova Lake, Diamond Rapids) and AMD Zen 6. This includes Intel TSX moving to auto-tune mode on newer Intel CPUs and DSA 3.0 accelerator support for offloading tasks to dedicated silicon on newer Xeons. If your lab has access to any Zen 6 or Diamond Rapids hardware, this is the release to establish your performance baseline on those platforms. JIT-compiled and AOT workloads are particularly worth profiling, as TSX auto-tuning can shift transactional memory behavior in ways that affect lock-heavy code paths in the runtime.
Rust officially stable in the kernel
The "Rust experiment" is formally concluded — Miguel Ojeda's patch marking Rust as no longer experimental landed in the 7.0 merge window. This is structurally significant for the kernel's trajectory: expect more subsystems to introduce Rust-authored drivers and components in subsequent releases. The direct performance impact in 7.0 is minimal, but it signals that memory-safety-motivated rewrites of kernel subsystems are now an ongoing concern rather than a speculative one. Worth noting in the context of your team's own memory safety work — the kernel and .NET are heading in the same direction.
XFS self-healing and filesystem improvements
7.0 includes meaningful XFS improvements. If any of your CI infrastructure, test machines, or container hosts run XFS, run I/O-bound benchmarks: NuGet restore,
dotnet build, assembly loading, and ReadyToRun image generation. These workloads are sensitive to filesystem metadata performance and are good at surfacing regressions that don't appear in synthetic I/O benchmarks.ARM64 LS64/LS64V 64-byte single-copy atomics
The ARM64 7.0 pull wires up 64-byte single-copy atomic load/store instructions (FEAT_LS64, FEAT_LS64V from Armv8.7), now exposed to userspace via
/proc/cpuinfoand hardware capabilities. Less immediately actionable for the runtime today, but relevant to AI enablement work — this is the primitive that ML inference runtimes and hardware-adjacent code can exploit for zero-copy data movement into accelerators. SVE vector length correctness on Cobalt 100 is also tracked in dotnet/runtime #101433, which notes that the JIT hardcodes 128-bit assumptions that should instead use the machine's current vector length.For Your Consideration
Baseline strategy matters more than usual this cycle
The mm/cid regression was introduced in 6.19 and fixed in 7.0-rc4, which means the 6.19 baseline is itself impaired for certain workloads. Establish three comparison points — 6.18 LTS (clean reference), 6.19 (to characterize the regression), and 7.0 (to confirm the fix) — rather than just comparing 7.0 to the most recent stable kernel. Without the 6.18 baseline, it's easy to misread the 7.0 improvement as a kernel gain when it's actually a 6.19 regression being resolved.
Ubuntu 26.04.1 is the real production target, not .0
Canonical confirmed that Ubuntu 26.04 may ship with a 7.0 RC and push the stable kernel via a Day-0 SRU. The 26.04.1 point release in August is when the LTS→LTS upgrade path opens and when most production .NET deployments will actually move. Testing now against 7.0 RCs is valuable for catching regressions early, but your definitive performance baseline for customer-facing guidance should be established against 26.04.1 when it ships.
Fedora 44 will likely ship with 6.19, not 7.0
The F44 beta shipped with kernel 6.19.2 and the final release targets April 14 — potentially before 7.0 stable lands on April 12 or 19. Fedora will pick up 7.0 via post-release updates quickly given its rolling-update philosophy, but don't assume F44 at launch is a 7.0 test environment. Plan to update the kernel explicitly after F44 GA rather than relying on the initial ISO.
Linus is watching the RC cycle size
rc2, rc3, and rc4 have all run above historical averages for their stage in the cycle. Linus attributed this partly to developer psychology around the new major version number, but by rc4 he revised his theory. If rc5 (due ~March 22) continues the trend, the probability of an rc8 and an April 19 GA increases — which tightens the window for both Fedora 44 and Ubuntu 26.04 to ship with a stable 7.0 kernel. Keep an eye on the rc5 LKML announcement when it drops this Sunday.