ByteDance 2026 Linux Kernel Review: 198 Commits, Preemptible IPI, Dying Memcg Fixes

Linux kernel runs on diverse infrastructure; every mechanism change must balance performance, correctness, maintainability, hardware differences, and long-term compatibility. Participating in the upstream community is not just submitting code — it includes abstracting production issues into general solutions, reviewing others' work, and maturing valuable changes together.

Upstream acceptance eliminates repeated local patch rebasing, reduces long-term maintenance cost, and exposes code to broader review and testing, improving quality. Continuous contribution turns engineers from users into ecosystem co-builders, keeping pace with kernel evolution.

By September 2026, 23 engineers contributed 198 commits accepted into Linux maintainer branches, covering memory management, scheduling, filesystems and I/O, RISC-V, virtualization, IOMMU, networking, performance tools, and kernel testing. The team also reviewed and advanced 113 community patches.

1. From Production Problems to General Kernel Capabilities

1.1 From 16.7 ms to 1.56 ms: Making IPI Wait Preemptible

In latency-sensitive workloads, a task's ability to obtain CPU promptly affects tail latency. Even a high-priority real-time task must wait if the current CPU stays in a non-preemptible state for too long.

In production DPDK workloads, some CPUs exhibited millisecond-to-tens-of-milliseconds non-preemptible events. Analysis showed most long tails came from remote TLB flushes triggered by process exit and memory free paths.

On x86, remote TLB flush uses inter-processor interrupts (IPIs). The kernel's smp_call_function family disables preemption during request preparation, IPI sending, and waiting for remote CPUs to finish. If a remote CPU has interrupts disabled or many CPUs must be waited on, the initiating task can remain non-preemptible for milliseconds.

The original flow can be simplified as:

Only target selection, request construction, and IPI sending truly require the current CPU. Waiting for remote completion does not require the task to stay bound.

Based on this observation, a 14-patch series redefined preemption boundaries in cross-CPU calls: preemption is re-enabled after request enqueue and IPI send, making the synchronous wait phase preemptible and migratable.

This was not a simple removal of preempt_disable. Restoring preemption meant the task could be switched or migrated, so per-CPU data lifetime and concurrency guarantees had to be re-established. The series introduced a task-local IPI mask and systematically handled CPU hotplug, CSD storage lifetime, x86 TLB flush, and virtualization backends (KVM, Xen, Hyper-V) that depend on CPU-local state.

In production, the P99 of maximum non-preemptible duration per 30-second window dropped significantly:

After applying the series, no non-preemptible events exceeding 1 ms were observed on arch_tlbbatch_flush and flush_tlb_mm_range paths. Microbenchmarks on x86 TLB flush data structures showed no measurable performance regression.

The change improved the fundamental condition for real-time tasks to obtain CPU promptly. The 90.7% figure measures the reduction in maximum non-preemptible duration P99.

The series went through 10 community iterations. Developers from scheduling, real-time, x86, and RCU subsystems participated in design discussion, code review, and testing. The design evolved from early stack-based cpumask with RCU protection to a cleaner task-local IPI state.

From a 16 ms production tail to a general kernel mechanism covering SMP, x86 MM, and virtualization paths, this work demonstrates a complete path from production practice to upstream.

1.2 After Container Exit: Systematically Solving Dying Memory Cgroup Problem

In container environments, when a task or container exits, its memory cgroup should be reclaimed. Reality is more complex: file pages and other memory objects may be shared across tasks, and their lifetimes can exceed the creating memcg. As long as these objects hold a reference to the original memcg, the deleted memcg cannot be freed, forming a dying memory cgroup.

Repeated container creation, exit, and re-accessing the same files causes file pages to be used by later instances, accumulating dying memcgs. This consumes memory and can reduce page reclaim efficiency. The issue has existed in the Linux community for years and is especially relevant in large-scale container environments.

The team submitted 33 patches. The solution prevents LRU folios from pinning the original memcg lifetime long-term and reparents resources when a memcg goes offline. Concurrency safety during lookup, reclaim, and reparenting is ensured via RCU, reference counting, and lruvec locks.

The changes span not just one function or reclaim path but cover traditional LRU, MGLRU, workingset, writeback, zswap, page migration, and other core modules. Because file pages can be shared, long-lived, and participate in reclaim or migration at any time, solving dying memcg requires systematically checking every user of memcg or lruvec pointers.

In a reproduction test creating and deleting 2000 memory cgroups while file pages spanned their lifetimes, the new scheme stopped dying memcg counts from growing significantly.

Beyond freeing kernel metadata, this work lets Linux more accurately manage cross-lifecycle file pages and reclaim state in environments with frequent container churn.

1.3 Restructuring Memory Metadata Infrastructure: Generalizing HVO

Linux maintains struct page metadata for each physical page. As system memory grows, this metadata becomes sizable. HugeTLB Vmemmap Optimization (HVO) reduces metadata overhead for huge pages by reusing portions of vmemmap pages.

The original HVO implementation had a special early-boot path for HugeTLB that established optimized mappings before the generic sparse-vmemmap process. Supporting this path required dedicated state in generic memory initialization code, making the mechanism hard to reuse and complicating boundaries between bootmem, memory hotplug, Device DAX, and architecture page-table operations.

In 2026, the team completed four interconnected pieces totaling 47 commits:

Fixed vmemmap optimization statistics and initialization errors in DAX, memory hotplug, and ZONE_DEVICE scenarios.

Restructured bootmem gigantic HugeTLB early allocation and initialization, fixing boot and architecture issues.

Unified duplicated vmemmap PMD operations across architectures into common helpers.

Introduced section-based optimization descriptors in sparse-vmemmap and migrated HugeTLB bootmem pages to this generic path.

In the new design, HugeTLB no longer creates its own special vmemmap mappings upfront. Instead, it records the compound page order in the corresponding memory section. The generic sparse-vmemmap population path uses section metadata to decide how to allocate or reuse tail vmemmap pages. After migration, the dedicated pre-initialization mechanism and a batch of redundant state can be removed.

The focus is not adding another local optimization but redrawing subsystem responsibilities: HugeTLB describes requirements, sparse-vmemmap implements generic optimization, and architecture code provides necessary page-table capabilities. This makes HVO easier to maintain and lays a foundation for future HVO users like Device DAX.

Around HugeTLB, the team also improved boot parameter reservation on large NUMA systems. On a 4-node, 384 GB x86 VM, the changes raised successfully reserved 2 MiB huge page capacity from under 374 GB to over 379 GB.

This phase completed HugeTLB migration to a section-based generic framework, setting the stage for Device DAX and other HVO applications.

1.4 Facing 25 Million struct page: Accelerating Large-Capacity Memory Device Initialization

When large-capacity PMEM, fsdax, and devdax devices come online, the kernel must initialize struct page for each physical page. For a 100 GB device, that means ~25 million highly similar metadata initializations. This overhead occurs synchronously in device probe, bind, or rebind paths, blocking user operations like device configuration, hot-add, resume, and rebind.

The proposed solution avoids repeating the full initialization for every struct page. Instead, it generates a correctly initialized template, then refreshes PFN-dependent fields and copies the template to subsequent pages. The approach covers both regular head pages and compound tail pages.

To further reduce write-allocate and cache pollution, the series introduced a memcpy_nontemporal interface in the kernel and extended a fixed-size MOVNTI fast path on x86. Platforms without architecture-specific backends fall back to regular memcpy, so the template copy itself is a cross-architecture optimization.

The series was validated in VM, physical machine, and arm64 environments:

arm64 tests did not use x86's MOVNTI fast path yet still showed clear improvement, proving the generic template copy mechanism benefits other architectures.

Tests used different architectures, page sizes, and device alignment configurations, verifying effectiveness across environments. All measurements are for the memmap_init_zone_device phase.

1.5 When Devices Are Fast Enough: iomap Fast Path for Small Direct I/O

As Gen5 NVMe and other high-speed storage devices improve, the bottleneck shifts from hardware to kernel software paths. In 4 KiB random read tests, raw block devices achieve ~3.2M IOPS, while ext4 or XFS iomap Direct I/O generic path delivers ~1.92M IOPS.

Profiling showed memory allocation, iomap state machine iteration, and async completion handling consume significant CPU time. For a simple read request that fits in a single filesystem block, requires no splitting, encryption, or special callbacks, the full generic path provides unused complexity.

The team created a lightweight fast path for qualifying small read-only Direct I/O requests. Request state and bio are allocated once; common success cases complete directly. Complex requests that don't meet criteria fall back to the original generic path, preserving existing functionality and semantics.

In single-core io_uring poll-mode tests, ext4 4 KiB random read performance rose from ~1.92M IOPS to ~2.19M IOPS. In a broader fio test matrix:

ext4 improved up to 10.06% across queue depths and I/O modes.

XFS improved up to 9.76%.

At low queue depths, performance matched the original implementation.

This case illustrates the value of Linux generic infrastructure: optimizing a common path in iomap benefits multiple filesystems simultaneously.

2. From Critical Mechanisms to Diverse Ecosystem

2.1 From Failure Scenes to Stable Kernel

Beyond full feature and optimization series, 52 accepted commits since 2026 explicitly reference fixed historical changes ( Fixes: tags), and 32 were CC'd to the stable kernel team. These fixes cover crashes, resource leaks, concurrency races, accounting errors, and hardware exceptions.

Some issues originated directly from complex production environments:

Device passthrough: PCIe endpoint link loss due to surprise removal or link failure. If Intel IOMMU still sends ATS invalidation to the inaccessible device and waits synchronously, the host can hardlockup. Fixes added device accessibility checks for both legacy and scalable modes, preventing QEMU/DPDK user-space device scenarios from expanding link failures into hardlockups.

Core scheduling: newidle balance could migrate a task while temporarily releasing the core-wide lock, causing the same task to be selected by two sibling CPUs simultaneously, triggering kernel warnings or crashes. The fix restored correct retry semantics under core scheduling.

Other representative fixes include:

VDUSE message timeout and read concurrency causing double list deletion.

HVO rollback restoring incorrect head-page metadata.

userfaultfd charging HugeTLB memory to handler memcg when filling for another process.

Resource leaks and races in memory hotplug, CMA, shrinker, and MGLRU.

Correctness issues in ext4, EROFS, NFS, FUSE, device-mapper, and network drivers.

These fixes may not each warrant a long story, but together they form the kernel community's essential daily work: root-causing real failures, pushing fixes to common code, and providing basis for stable kernel backports.

2.2 Extending to More Architectures: Page Table Reclaim and RISC-V Ecosystem

On memory reclaim, the team extended PT_RECLAIM (page table reclaim) to more architectures. On 64-bit systems, madvise(MADV_DONTNEED) on mappings over 100 GB can leave many empty PTE page-table pages. Eight patches refined Kconfig dependencies and added required capabilities for alpha, UML, parisc, MIPS, and LoongArch, enabling PT_RECLAIM by default on more platforms.

RISC-V contributions span memory management, performance analysis, exception handling, and virtualization:

Using ASID in update_mmu_cache path, adopting Svinval when available.

Fixing THP split page-table-check miscounting of temporarily invalid PMDs.

Improving ftrace, stacktrace, and kprobes correctness.

Adding hardware error trap handler support.

Fixing hwprobe initialization timing vs. user-space startup.

Enhancing KVM guest interrupt file and instruction extension support.

Simultaneously, the team contributed fixes to perf, ftrace, cgroup selftests, and livepatch selftests. Stable kernel usage depends on both core implementation and evolving verification tools.

3. Two-Way Participation: Contributing Solutions and Reviewing Community Code

The Linux kernel is a global collaborative project. A patch's journey from proposal to merge requires not only author design and implementation but also review by developers familiar with the subsystem for correctness, concurrency boundaries, architecture differences, and long-term maintenance cost.

The team invests in deep review of others' patches because the kernel is shared infrastructure: community contributions enter the kernels they use, and their quality directly affects business stability and performance. Review is not one-way giving; it's a mutually beneficial process — helping contributors find potential issues, clarify design boundaries, validate configurations, and produce more maintainable solutions. Polished improvements then flow back into production, creating a virtuous cycle.

This sustained investment is reflected in formal community roles. Multiple engineers are now listed in the kernel's MAINTAINERS file as maintainers or reviewers in core subsystems like memory management. One engineer serves as HugeTLB subsystem maintainer and handles memcg and shrinker reviews. Others review shrinker, MGLRU, reclaim, RISC-V QoS Resctrl, zswap, and KSM. Another engineer is vice-chair of the RISC-V International Hypervisor SIG. These roles recognize technical capability and imply ongoing responsibility for code quality and long-term evolution.

3.1 Applying Accumulated Experience to Help More Contributors

Since 2026, the team contributed 76 Reviewed-by and 48 Acked-by tags across 113 distinct patches.

Reviews focus on core memory management mechanisms: HugeTLB, memcg and shrinker, vmscan, sparse-vmemmap, and page table reclaim.

3.2 From Memory Management to Virtualization, Storage, Scheduling, and RISC-V

Of the reviewed patches, 82 are in the mm/ directory. Review footprints also extend to kernel core, VDUSE, HugeTLB filesystem, iomap, x86 memory management, live update, and RISC-V ecosystem building.

Key review participation includes VDUSE, iomap, block device polling, scheduler cgroup migration, and RISC-V ecosystem patches, bringing production experience in virtualization, storage, and scheduling into broader community collaboration.

3.3 Co-Refining Solutions in Open Collaboration

The team's own submissions also evolve through community review. The preemptible IPI wait series went through 10 versions; feedback drove changes to cpumask storage, CPU hotplug lifetime, x86 stack object alignment, virtualization backend protection boundaries, and added build fixes, microbenchmarks, and torture tests.

HVO work was split and reorganized into independently reviewable steps: bootmem HugeTLB restructuring, correctness fixes, generic PMD helpers, and section-based HVO. The iomap fast path, under filesystem community review and integration, became a strictly bounded, generic implementation serving both ext4 and XFS.

By accepting global review of our code and using Reviewed-by / Acked-by to help others advance, the team engages in bidirectional collaboration that sustains long-term Linux kernel evolution.

4. Continuously Turning Production Practice and Technical Judgment into Community Capability

Since 2026, the team's Linux kernel contributions comprise 198 accepted commits and review coverage of 113 community patches. More important than the numbers is the continuous cycle they form: discover and reproduce issues from production, dive into core code for root causes; propose maintainable, verifiable general solutions; refine designs through community feedback; apply accumulated technical judgment to review others' work.

From improving real-time task scheduling tails to governing post-container-exit memory lifecycles; from evolving HVO infrastructure to boosting large memory device and high-speed storage efficiency; from contributing patches to helping community developers refine valuable changes — the team will continue participating in Linux kernel community building, advancing foundational software evolution alongside global developers.