Linux 6.19 Scheduler Feature Being Disabled Due To Performance Regressions

The Linux kernel's scheduler is a complex, constantly-evolving subsystem that directly impacts how every process on a system gets CPU time. In the Linux 6.19 merge window, a feature called NEXT_BUDDY was re-introduced after being adapted for the new EEVDF (Earliest Eligible Virtual Deadline First) scheduler. However, real-world benchmarking has revealed performance regressions in critical workloads, prompting a one-line patch to disable the feature by default. This decision underscores the difficulty of balancing scheduler theory with practical application performance.

What is NEXT_BUDDY?

NEXT_BUDDY is a scheduler heuristic designed to improve cache locality. The core idea is simple: when a task finishes executing on a CPU, the scheduler tries to schedule the same task's "next" sibling (if one exists) on the same CPU. This aims to keep related threads of a process on the same core, reducing cache misses and improving performance for multi-threaded applications.

The feature was originally present in the kernel but was disabled when the scheduler was migrated to EEVDF. EEVDF is a more sophisticated scheduling algorithm that uses virtual deadlines to provide better fairness and latency guarantees. The re-implementation of NEXT_BUDDY for EEVDF (commit e837456fdca8) aimed to align the buddy heuristic with EEVDF's goals, hoping to provide the cache benefits without disrupting the fairness model.

The Performance Regressions

Despite the theoretical benefits, testing has shown that the re-implemented NEXT_BUDDY causes performance degradation in several key scenarios. The patch disabling it, queued into the kernel's sched/urgent branch, lists specific regressions:

1. MySQL Client/Server on Different Servers: A realistic database workload where the MySQL client and server run on separate physical machines shows a performance regression. This is particularly concerning because it represents a common deployment pattern in production environments.
2. SPECjbb: The SPECjbb benchmark, which simulates a Java application server, reports lower peak performance metrics. The patch notes a need to verify if this is simply shifting the point where peak performance is measured, but it remains a concern.
3. DayTrader: This financial trading application benchmark is considered representative of a real-world, latency-sensitive workload. A regression here indicates a tangible impact on application performance.

The patch message explicitly states: "The mysql is realistic and a concern." It also acknowledges that while some workloads saw gains, the regressions are significant enough to warrant a temporary disablement. The decision was made because "Access to test machines is currently problematic for verifying any fix to this problem."

Context from Earlier Benchmarking

This issue was not caught in isolation. In early December 2025, during initial Linux 6.19 benchmarking, regressions were identified in an Nginx HTTPS web server workload. A bisect of the kernel history pointed to the e837456fdca8 NEXT_BUDDY commit as a potential culprit for at least part of that regression. While not all regressions were fully bisected, this provided early warning signs that the feature was not a universal win.

The Trade-Off: Theory vs. Reality

The NEXT_BUDDY saga is a classic example of the challenges in kernel scheduler development. Scheduler algorithms are designed around models of system behavior, but real-world applications often behave in ways that defy those models. EEVDF aims for fairness and predictable latency, but application-level performance can be sensitive to factors like cache behavior, memory access patterns, and inter-thread communication in ways that a pure scheduling algorithm may not account for.

NEXT_BUDDY attempts to optimize for cache locality, a well-known performance factor. However, its implementation within EEVDF may have inadvertently disrupted the scheduler's fairness guarantees or introduced latency spikes for certain task patterns, leading to the observed regressions. The patch to disable it is a pragmatic response: when a feature causes measurable harm in important workloads, it's better to revert and study the problem than to push forward with a known issue.

What Happens Next?

With the patch queued for the sched/urgent branch, it will likely be merged into the mainline Linux kernel in the coming days as part of the 6.19 release cycle. This means the default 6.19 kernel will not have NEXT_BUDDY enabled, and systems running it will not see the regressions reported in MySQL, SPECjbb, and DayTrader.

However, this is not the end of the story. The developers will need to investigate the root causes of the regressions. This involves deep analysis of how NEXT_BUDDY interacts with EEVDF and the specific workload patterns that trigger the performance drops. Future kernel versions may see a revised implementation of NEXT_BUDDY that addresses these issues, or the feature may remain disabled indefinitely if the trade-offs are deemed unacceptable.

For users and administrators, this is a reminder that kernel updates can have unpredictable performance impacts. While the Linux kernel community is diligent about testing, the vast array of hardware and software combinations means that some regressions only surface in widespread deployment. The decision to disable a feature based on real-world data is a sign of a healthy, responsive development process.

The image above, a social media preview, reflects the community discussion around such kernel changes. As the patch moves through the mainline, developers and users will be watching closely to see if the regressions are resolved and whether NEXT_BUDDY can be safely re-enabled in a future kernel release.

The Linux kernel's scheduler, as represented by the "LINUX KERNEL" image, is a foundational component of the entire operating system. Changes to it are always made with caution, but as this case shows, even well-intentioned optimizations can have unintended consequences. The ongoing work to refine the scheduler, including the EEVDF project and related features like NEXT_BUDDY, continues to be a critical area of development for the Linux ecosystem.

The current situation with NEXT_BUDDY highlights a key principle in systems engineering: performance is not a single metric. It's a balance of throughput, latency, fairness, and consistency across a diverse set of workloads. A feature that improves one metric for some applications may degrade another for others. The scheduler's job is to find the best possible compromise, and sometimes that means taking a step back to reassess the approach.