Fact-checked by Grok 2 weeks ago

Brain Fuck Scheduler

The Brain Fuck Scheduler (BFS) is a process scheduler for the , developed by in August 2009 as an alternative to the mainstream (CFS), emphasizing simplicity, low latency, and optimal performance on desktop and low-specification hardware rather than scalability for large server systems. Unlike the O(log n) complexity of CFS, which uses red-black trees for fair CPU allocation based on virtual runtime, BFS employs an approach with a single global treated as a to prioritize rigid fairness and immediate task responsiveness. Its design rejects complex heuristics like variable timeslice lengths or sleep-based CPU distribution, instead aiming to eliminate scheduler-induced stalls and deliver consistent even under load on multicore systems up to around 16 logical CPUs. BFS was created out of frustration with the unpredictability and overhead of prior schedulers, with Kolivas opting for a "forward-looking" model that maximizes efficiency on consumer-grade machines without support for features like control groups () or NUMA-aware balancing in its core implementation. Key features include support for scheduling classes such as SCHED_ISO for guaranteed and SCHED_IDLEPRIO for tasks, alongside recommendations for configurations like 1000 Hz tick rates and full preemption to achieve the lowest possible . Benchmarks have shown BFS outperforming CFS in workloads, such as faster times on quad-core systems and reduced input lag in interactive applications, though it degrades on high-core-count servers due to its linear scanning overhead. Maintained out-of-tree by Kolivas until around , BFS has not received further updates for subsequent versions and has largely been superseded by its successor MuQSS, though it remains appealing to users prioritizing responsiveness over enterprise scalability.

Introduction and History

Overview

The Brain Fuck Scheduler (BFS) is an alternative process scheduler for the Linux kernel, developed by Con Kolivas, a prominent contributor to Linux kernel scheduling subsystems who previously worked on improvements to the O(1) scheduler. Introduced in August 2009 as an out-of-tree patch, BFS was created to address perceived shortcomings in mainstream schedulers by prioritizing simplicity and performance on typical desktop environments. It operates under the GNU General Public License (GPL), consistent with Linux kernel contributions. BFS was specifically designed as a responsive scheduler for low-to-mid-spec systems, focusing on desktop interactivity and low latency rather than scalability for high-end servers with thousands of cores. Its core aim is to deliver fair process allocation without the computational overhead of more complex algorithms, enabling better responsiveness for interactive tasks without requiring user-level tuning. In contrast to the Completely Fair Scheduler (CFS), which emphasizes scalability across diverse workloads, BFS seeks to minimize scheduling complexity to enhance real-time feel on consumer hardware. The project reached its final stable release, version 0.512, on October 3, 2016, supporting Linux kernel 4.8 as part of the ck patchset. Thereafter, Kolivas shifted focus to successor projects, but BFS remains available for integration into custom kernels targeting desktop optimization.

Development Timeline

The Brain Fuck Scheduler (BFS) was developed by Con Kolivas in response to the perceived over-complexity of the Completely Fair Scheduler (CFS), which had been introduced in the Linux kernel in 2007 and prioritized scalability over desktop responsiveness. Kolivas aimed to revive the simplicity of the earlier O(1) scheduler while addressing issues like random stalls and poor interactivity on lower-spec machines, focusing on purpose-built design for typical desktop workloads rather than massive multi-core systems. BFS's initial release, version 0.1, occurred in August 2009 for Linux kernel 2.6.30, with rapid iterations driven by community feedback to refine its virtual deadline-based approach. A significant milestone came in September 2011, when version updates for the 3.0 kernel series incorporated a skip list data structure for the runqueue, replacing linear searches with logarithmic-time insertions and constant-time lookups to enhance efficiency under high task loads without compromising low-latency performance. Development continued out-of-tree through the early , with ongoing patches maintained by Kolivas and the to ensure compatibility with evolving . By 2016, active development of BFS culminated in version 0.512 for 4.8, after which Kolivas shifted focus to its successor, the Multiple Queue Skiplist Scheduler (MuQSS). In 2021, Kolivas announced the discontinuation of the ck patchset and MuQSS maintenance due to lack of motivation, though efforts, such as the pf-sources kernel, have sustained BFS patches for kernels up to the 6.x series as of 2025. BFS draws loose influences from academic scheduling theory, particularly Earliest Eligible Virtual Deadline First (EEVDF) for prioritizing tasks by virtual deadlines and the Staircase Deadline model from Kolivas's prior work on fair timeslicing.

Core Design Principles

Theoretical Foundations and Efficiency

The Brain Fuck Scheduler (BFS) employs the Earliest Eligible Virtual Deadline First (EEVDF) algorithm as its core scheduling mechanism, which prioritizes tasks based on their computed virtual runtime deadlines to ensure fair and responsive execution. This approach, loosely inspired by earlier deadline-based schedulers, calculates an effective virtual deadline for each task to determine eligibility, allowing the scheduler to select the task with the earliest deadline for execution on any available CPU. BFS utilizes a single global runqueue shared across all CPUs, implemented initially as a that supports O(1) insertion for new tasks while requiring O(n) worst-case lookup to identify the eligible task. This design simplifies by eliminating per-CPU queues and complex balancing logic, promoting better load distribution and reduced overhead in multi-core environments up to moderate scales. In terms of efficiency, BFS significantly reduces kernel code complexity, comprising approximately 9,000 fewer lines than the (CFS) in 2.6.31, by avoiding intricate heuristics and focusing on straightforward, constant-time operations where feasible. The scheduler emphasizes interactivity for desktop workloads without incorporating sleep-time accounting or priority boosting mechanisms, instead leveraging virtual deadlines to maintain low-latency task switching and rigid fairness. Tasks in BFS receive a default time slice of 6 ms, which can be adjusted through the rr_interval tunable parameter up to a maximum of 300 ms to accommodate varying workload requirements. For , BFS is optimized for systems with up to 16 cores, prioritizing the utilization of idle CPUs over cache affinity considerations to enhance overall responsiveness on typical desktop hardware.

Virtual Deadline Mechanism

The virtual deadline mechanism serves as the projected finish time for a task's allocated time slice in the Brain Fuck Scheduler (BFS), enabling task prioritization and ordering within the single global runqueue. This approach, inspired by earliest eligible virtual deadline first (EEVDF) principles, assigns each runnable task a deadline upon enqueueing or time slice refill, allowing the scheduler to select and preempt based on the earliest deadline to ensure timely execution. The virtual deadline is computed using the formula: virtual deadline = current time + (prio_ratio × rr_interval), where the current time is measured in jiffies or high-resolution niffies, prio_ratio is the nice-adjusted factor, and rr_interval is the tunable interval representing the base time slice (default 6 ). The prio_ratio is calculated as a ratio relative to nice -20, increasing by 10% (multiplicative factor of 1.1) for each higher nice level and decreasing similarly for lower levels, effectively incorporating load by spacing deadlines relative to overall contention without explicit per-task . In practice, this manifests as the fixed prio_ratio multiplier on the slice, where prio_ratio = 1.1(nice + 20) relative to the baseline nice value of -20. Tasks become eligible for scheduling immediately upon insertion into the runqueue, at which point their virtual deadline is assigned; the scheduler then selects the eligible task with the earliest virtual deadline through a linear scan of the queue, enabling straightforward prioritization without complex data structures. Nice values adjust virtual deadlines exponentially via the prio_ratio, with each increment shifting the multiplier to delay lower-priority tasks; for instance, a +10 nice adjustment effectively more than doubles the effective priority spacing, as the relative CPU share scales inversely with the squared prio_ratio difference, ensuring higher-nice tasks yield proportionally more CPU time to others. The mechanism handles CPU bursts by extending deadlines in proportion to usage: upon time slice depletion, the task's quota is refilled to rr_interval, and a new deadline is computed from the current time, preserving fairness during prolonged execution while allowing preemption by higher-priority arrivals. This mechanism benefits normal tasks by enforcing fairness through deadline-based ordering in a unified runqueue, eliminating per-CPU queues and their associated overhead, while promoting low-latency wakeups as newly eligible tasks with early deadlines can immediately preempt running ones for improved interactivity.

Scheduling Policies

Realtime Policy

The realtime policy in the Brain Fuck Scheduler (BFS) represents the highest priority class, functioning similarly to in conventional scheduling by assigning tasks to one of 100 dedicated priority queues based on static priorities ranging from 1 to 99, thereby overriding any virtual deadline mechanisms used in lower tiers. This strict hierarchical prioritization ensures that realtime tasks preempt all non-realtime processes, with scheduling decisions made via an efficient scan of the queues to select the highest-priority eligible task in O(1) time for queue identification. Under this policy, tasks execute until completion, voluntarily yielding, or being preempted by a higher-priority task, without enforcement of time slices or deadlines, which promotes deterministic for latency-sensitive workloads while relying on system resource bounds to prevent indefinite blocking. Within the same priority level, tasks follow ordering, meaning the first enqueued task runs first, enhancing predictability in multi-task environments. This policy is well-suited for hard realtime applications, such as audio processing or control systems, where consistent low-latency response is paramount to avoid glitches or failures. For instance, it supports scenarios requiring immediate CPU access without the overhead of fairness computations found in normal policies. A key limitation is the potential for lower-priority tasks to starve if high-priority tasks dominate the CPU for extended periods, though BFS mitigates this risk through its single global runqueue, which allows system-wide visibility and opportunistic migration to underutilized cores on multi-processor systems. Abuse of elevated priorities by unprivileged users is further discouraged by capabilities checks. Tasks are assigned to the realtime policy via the sched_setscheduler() , specifying SCHED_FIFO and a priority value between 1 and 99, with user-space tools like schedtool providing a convenient for .

Isochronous Policy

The Isochronous Policy, known as SCHED_ISO in the Brain Fuck Scheduler (BFS), serves as the second-highest priority scheduling class, positioned between hard policies (SCHED_FIFO and SCHED_RR) and the normal policy (SCHED_NORMAL). It is specifically designed for soft applications, such as tasks like video playback and audio processing, where consistent performance is essential but absolute guarantees are not required. Unlike hard scheduling, SCHED_ISO employs virtual deadlines to approximate isochronous behavior, ensuring tasks receive timely execution while incorporating resource limits to maintain system stability. This policy allows unprivileged users to achieve near- performance without risking kernel instability from unrestricted access. A key feature of SCHED_ISO is its CPU usage cap, enforced through the tunable iso_cpu, which defaults to 70% of total CPU across all cores, measured over a 5-second rolling average. If SCHED_ISO tasks exceed this limit, they are automatically demoted to SCHED_NORMAL, preventing any single class from monopolizing resources. Tasks under this policy receive dedicated time slices in a manner at the rate defined by the rr_interval tunable (default 6 ms), with scheduling decisions based on earliest eligible virtual deadline first (EEVDF), where deadlines are computed as current jiffies plus (priority ratio times rr_interval). SCHED_ISO tasks SCHED_NORMAL processes but to higher-priority tasks, and they use ordering within the policy's single queue. Additionally, the policy acts as a transparent fallback: when unprivileged processes request scheduling (e.g., via libraries like JACK for audio), BFS elevates them to SCHED_ISO instead of denying the request. Implementation of SCHED_ISO in BFS occurs within the global runqueue (GRQ) structure, protected by locks such as grq.iso_lock for tracking CPU consumption via iso_ticks. Periodic checks enforce the iso_cpu limit, with demotion handled automatically and requiring privileges to revert. Child processes inherit the SCHED_ISO class from parents, facilitating consistent behavior in pipelines. On multi-core systems, SCHED_ISO tasks can migrate for load balancing but prioritize low-latency execution on available CPUs. Tools like schedtool enable , for example, schedtool -I -e <application> to run a under this . The advantages of SCHED_ISO include enhanced responsiveness for desktop multimedia applications, such as smooth video decoding without audio glitches, by providing prioritized access without the risks of full privileges. It mitigates CPU for lower-priority tasks and improves overall system stability on lower-spec hardware, where BFS excels, by capping resource use and avoiding the spikes common in other schedulers on (SMP) setups. This design simplifies -like scheduling for unprivileged users, reducing the need for complex tuning while promoting for soft workloads.

Normal Policy

The Normal Policy, also known as SCHED_NORMAL, serves as the third priority tier in the Brain Fuck Scheduler (BFS), handling the majority of user-space applications such as interactive programs. It employs virtual deadlines to allocate proportionally according to each task's nice value, ensuring that higher-priority tasks receive more frequent execution opportunities while maintaining overall system fairness. This policy is the default for non-realtime workloads, prioritizing low-latency responsiveness without providing hard guarantees typical of higher-priority tiers. Fairness in the Normal Policy is achieved through a mechanism where runnable tasks share the CPU inversely proportional to the number of active tasks at the same level, with virtual deadlines serving as the key to track and balance usage over time. The scheduler selects the task with the earliest virtual deadline for execution, which effectively prevents by progressively advancing deadlines based on accumulated runtime and , allowing lower-priority tasks to eventually compete for CPU cycles. Unlike more complex estimators, BFS avoids sleep-time credits, instead relying on forward-looking deadline calculations to promote equitable sharing among competing processes. Under the Normal Policy, tasks within the same nice level operate in a round-robin fashion, each receiving up to the interval (default 6 ms) before yielding to the next eligible task. Newly woken tasks can preempt a running task if their virtual deadline is earlier, enhancing by minimizing delays for responsive applications. To ensure precise measurement of CPU consumption, the policy incorporates subtick accounting via the (TSC), which tracks actual usage at a finer than traditional tick-based methods, reducing inaccuracies in short-running bursts. Nice value adjustments under this policy span 40 levels, from -20 (highest ) to +19 (lowest), with each increment altering the by approximately 10% relative to the -20 baseline, leading to exponentially scaled CPU allocation—for instance, a nice value of -10 results in approximately 2.6 times the CPU share of the default nice 0 due to the smaller and deadline increment. This scaling ensures that user-niced processes, such as background compiles set to nice +19, consume negligible foreground resources while still progressing. Overall, the Normal Policy is optimized for general-purpose desktop environments, delivering bounded latencies suitable for interactive workloads like web browsing and office applications.

Idle Priority Policy

The Idle Priority Policy in the Brain Fuck Scheduler (BFS) represents the lowest scheduling tier, designated for non-interactive background tasks such as system backups, operations, or clients like and mprime. These tasks are assigned to the SCHED_IDLEPRIO class, ensuring they execute only when no higher-priority tasks—such as those under , isochronous, or normal policies—are runnable, thereby preventing any interference with interactive or foreground workloads. Under this , deadlines are applied to tasks but by an extremely large value, effectively deferring their eligibility far beyond typical loads and mimicking an effective of +40 to guarantee minimal CPU interference. Tasks are ordered by these deadlines within the single SCHED_IDLEPRIO ; the as a whole remains subordinate to all other tiers. Users can assign this to processes via tools like schedtool, for example, schedtool -D -e mprime to run a prime-testing utility without impacting responsiveness. This design intent prioritizes full CPU utilization for higher-priority tasks under load, allowing background maintenance to proceed opportunistically during idle cycles without compromising overall system interactivity. In practice, SCHED_IDLEPRIO tasks may temporarily elevate to normal scheduling if the system detects prolonged idle states or specific conditions like I/O waits, but they revert upon activity to maintain strict deferral.

System Mechanisms

Preemption Model

The Brain Fuck Scheduler (BFS) employs both voluntary and involuntary preemption mechanisms to manage task switching, prioritizing low-latency responsiveness on desktop and low-end systems. Voluntary preemption occurs at the end of a task's time slice, enforced by timer interrupts rather than explicit yield calls, which eliminates unnecessary context switches and reduces overhead. This approach relies on subtick precision accounting, utilizing the (TSC) clock for accurate CPU usage measurement down to levels, thereby minimizing in slice enforcement and ensuring fair allocation without sampling inaccuracies common in tick-based systems. Involuntary preemption is triggered primarily through wakeup events, where a newly awakened task evaluates its virtual deadline against the currently running task on any CPU. If the woken task has an earlier effective deadline—indicating it has not yet consumed its CPU quota—it preempts the to maintain and reduce . For tasks under policies like SCHED_FIFO or SCHED_RR, preemption is unconditional, allowing them to any lower-priority task across the system via the global runqueue. In contrast, for normal-priority wakeups (SCHED_NORMAL), preemption occurs only if the deadline advantage exceeds a configurable threshold, such as the round-robin interval (default 6 ms), preventing excessive switching for marginal gains. This wakeup-preemption strategy enhances overall system responsiveness by immediately prioritizing interactive tasks, but it involves an scan of the global runqueue on each wakeup, where n is the number of queued tasks, potentially impacting on high-load systems. To mitigate this, BFS incorporates sticky task affinity, flagging involuntarily descheduled tasks to bias their rescheduling toward the original CPU, particularly in multi-core environments with like the governor; this reduces cross-CPU migrations and limits the effective scan scope without compromising deadline fairness.

Multi-Core Task Placement

The Brain Fuck Scheduler (BFS) handles multi-core environments through a single global runqueue shared across all CPUs, allowing the scheduler to select and dispatch any eligible task irrespective of its previous core assignment. This unified structure simplifies by avoiding per-CPU runqueues, enabling direct to the entire pool of ready tasks ordered by priority and deadline. All CPUs compete for tasks from this , which is protected by a global to ensure consistency, though this introduces potential contention under high load. Task placement emphasizes preserving cache to minimize overhead from migrations. When waking a task, BFS prefers the originating core where it last ran, using heuristics such as adjusting the virtual runtime by a factor (e.g., multiplying by 8 for cross-core considerations) to discourage unnecessary moves unless the local core is idle or a significant exists elsewhere. CPU masks set by applications are respected where feasible, with placement decisions factoring in core distances—typically set to 3 in non-NUMA systems—to favor locality and reduce data movement costs. Migrations are thus limited to scenarios that promote overall system efficiency, such as directing tasks to idle cores during wakeups. Load balancing in BFS occurs implicitly through the global runqueue, as all cores draw tasks in deadline order without dedicated algorithms, ensuring fairness by proxy while avoiding the overhead of explicit redistribution. Periodic evaluations pull tasks from overloaded cores to idle ones when imbalances arise, prioritizing low-latency placement for interactive workloads. However, this design trades for simplicity: the scan of the runqueue—where n approximates the number of active tasks or CPUs—performs well up to 16 cores but degrades beyond that due to increased lock contention and scan times, leading to elevated latencies on larger systems.

Implementation and Tools

Runqueue Structure and Tunables

The runqueue in the Brain Fuck Scheduler (BFS) employs a single shared structure across all CPUs to enforce strict fairness through earliest-deadline-first ordering. Early implementations used a doubly linked list, which supported O(1) insertion and removal operations but incurred O(n) complexity for selecting the next runnable task, where n represents the number of tasks in the queue. To mitigate scalability limitations on multi-core systems, BFS adopted a skip list data structure starting from version 0.502. This probabilistic structure maintains tasks sorted by virtual deadline, achieving O(log n) insertion and amortized O(1) selection of the highest-priority task on average, while keeping removal efficient at O(1) in typical cases. BFS utilizes subtick accounting to precisely measure task CPU consumption without incurring the full overhead of scheduler ticks. By estimating usage in fine-grained subtick units derived from the timestamp counter where available, this approach improves accuracy in virtual runtime calculations and avoids the inaccuracies of coarse tick-based tracking. Several kernel tunables exposed via /proc/sys/kernel/ allow runtime adjustment of BFS behavior. The parameter sets the round-robin time slice duration, defaulting to 6 milliseconds to balance responsiveness and throughput. The iso_cpu tunable caps aggregate CPU utilization for isochronous-priority tasks at 70% by default, ensuring they do not monopolize resources at the expense of other classes. As an out-of-tree patch maintained by , BFS integration necessitates applying the patchset to sources and compiling a custom image. Community efforts provide backported patches for compatibility with legacy versions, including 3.15. BFS prioritizes code simplicity, with its initial stable release comprising approximately 9000 fewer lines than the contemporary in the mainline , reflecting a deliberate focus on over feature complexity.

schedtool Utility

The schedtool utility is a command-line tool designed to query and set CPU scheduling parameters for processes in , enabling users to assign scheduler policies, priorities, and CPU affinities without requiring kernel recompilation. It serves as the primary user-space interface for interacting with advanced scheduling features, particularly those introduced in the ck patchset, including the Brain Fuck Scheduler (BFS). Key commands allow specification of BFS-compatible policies directly when launching or modifying processes. For realtime scheduling under SCHED_FIFO or SCHED_RR, users can employ options like schedtool -R -p 50 -e command to set realtime policy with priority 50 for the specified command, or schedtool -F -p 10 <PID> to adjust an existing process ID to FIFO realtime with priority 10. Isochronous mode, useful for low-latency multimedia applications, is invoked with schedtool -I -e mplayer video.avi to run the media player in SCHED_ISO class. For normal priority adjustments, schedtool -N -n 10 <PID> shifts the nice value by 10, while idle priority under SCHED_IDLEPRIO uses schedtool -D -e command to ensure the process runs only during idle CPU time. Schedtool fully supports all BFS scheduling classes—realtime (FIFO/RR), isochronous (ISO), normal, and idle —allowing seamless policy assignment for diverse workloads. Additionally, it provides CPU affinity controls via the -a , such as schedtool -a 0x1 <PID> to bind a to CPU 0 or schedtool -a 0,3 <PID> for CPUs 0 and 3, optimizing multi-core placement without invasive system changes. These features make it indispensable for tuning desktop responsiveness and application performance in BFS-enabled environments. Installation of schedtool is straightforward as a standalone package in major distributions, including , , , and Sabayon, where it is bundled to complement BFS adoption. In ck patch contexts, it integrates directly with patched kernels but remains a separate user-space component, available via standard package managers or source compilation from its repository.

Performance Evaluation

Benchmarks

Benchmarks for the Brain Fuck Scheduler (BFS) have primarily focused on desktop interactivity, , and throughput in workloads such as compilation, compression, and multimedia processing, using tools like kernel compilation, for compression, for video encoding, and cyclictest for measuring wake-to-run and . These evaluations were conducted on ranging from single-core netbooks to multi-core desktops and servers, often comparing BFS to the default (CFS) in the . Methodologies typically involved patching the kernel with BFS (e.g., versions 211 for Linux 2.6.31 or 0.406 for Linux 3.0), disabling dynamic ticks, enabling preemption, and running tests via the on distributions like . In early tests on 2.6.31.6 across netbooks, laptops, and desktops, BFS demonstrated superior latency in bzip2 compression scenarios with multiple background processes, showing lower average and maximum latencies compared to CFS, which excelled in overall s for the same tasks. For video playback using on Big Buck Bunny footage, BFS significantly reduced under heavy multi-client loads (1-25 instances), making it more suitable for interactive desktop use, while CFS experienced higher frame drops. Kernel compilation tests, such as building with make -j matching core count, revealed mixed results, with BFS performing comparably or slightly better on low-spec single-core systems but lagging in oversubscribed multi-core environments where CFS minimized . These findings highlight BFS's strengths on resource-constrained like single-core netbooks. Later benchmarks on 3.0 with an i5-2500K quad-core processor showed BFS outperforming CFS by approximately 5% in single-core web server requests per second (13,180 vs. 12,569), but underperforming by approximately 26% in quad-core configurations (24,335 vs. 33,095 requests per second), indicating poorer scaling for high-throughput server workloads. In and encoding tests via the , such as and , differences were minimal on modern multi-core systems, though BFS provided marginally better results in some interactive scenarios. measurements using cyclictest in interactive tests revealed minor reductions in wake-to-run times with BFS on setups, enhancing perceived responsiveness. On low-spec , BFS consistently showed gains in compile times and by 1-8% across 1-16 core machines. Independent evaluations using the from 2009 to 2013 confirmed gains for BFS in desktop-oriented workloads like single-threaded and latency-sensitive tasks, but noted losses in high-throughput benchmarks where CFS scaled better. No official benchmarks post-2016 have been published, as BFS maintenance ceased around that time with the development shifting to its successor MuQSS; most data stems from 2009-2013 and Phoronix tests, with no new evaluations as of 2025.

Comparisons to Other Schedulers

The Brain Fuck Scheduler (BFS) employs a simpler design than the (CFS), utilizing a single global runqueue for all tasks rather than CFS's per-CPU red-black trees, which reduces complexity but introduces O(n) lookup times compared to CFS's O(log n) efficiency. This simplicity in BFS enhances desktop latency and interactivity for workloads with frequent I/O or user input, outperforming CFS in such scenarios, while CFS provides fairer for server environments with high CPU-bound task loads. As a successor to Con Kolivas's earlier O(1) scheduler, BFS abandons the multi-queue active and expired lists per CPU in favor of a unified global queue, prioritizing straightforward implementation and improved responsiveness without the overhead of those structures. This shift maintains O(1)-like interactivity gains but at the cost of dropping per-CPU optimizations that aided scalability in the O(1) design. BFS excels in systems with fewer than 16 cores, delivering lower and better performance for applications due to minimized scheduling overhead, but it suffers from increased lock contention and poorer throughput on 32+ core setups where global queue access becomes a bottleneck. Consequently, BFS was never integrated into the mainline owing to these scalability limitations, positioning it as a specialized option rather than a general-purpose replacement. As of 2025, CFS continues as the default scheduler in the , with BFS regarded in technical discussions as a niche for tuning systems and low-core desktops seeking enhanced responsiveness. Critics have noted that BFS lacks advanced heuristics for (NUMA) awareness or dynamic , rendering it unsuitable for modern multi-socket or energy-sensitive hardware, and some developers have labeled its global approach as inherently anti-scalable for large-scale deployments.

Adoption and Legacy

Distribution and Community Adoption

The Brain Fuck Scheduler (BFS) saw adoption as the default in several distributions focused on desktop performance. Sabayon Linux integrated BFS starting with version 7 in 2011 for enhanced responsiveness. Similarly, adopted BFS in its kernels from 2010 onward to achieve low-latency desktop scheduling. Zenwalk, a derivative, shipped BFS as its default scheduler since 2010, emphasizing lightweight and tuned environments. In the broader Linux community, BFS gained traction through integration into the Con Kolivas (CK) patchsets, which combined it with other enhancements for desktop interactivity and were widely applied to custom kernels. It became popular among desktop enthusiasts in forums such as and the Arch Linux (), where users discussed its application for latency tuning on lower-spec machines. Early experimentation with BFS occurred in Android custom kernels, such as , around 2010, though it faced issues with Android's and was not widely adopted due to scalability concerns on mobile devices. BFS reached its peak adoption from 2009 to 2014, during which users reported smoother multitasking on desktops with fewer than 16 cores. Adoption declined after 2016 as improvements to the mainline Completely Fair Scheduler (CFS) addressed many of the latency concerns that BFS targeted, reducing the need for the out-of-tree alternative.

Criticisms and Current Status

Critics have pointed out that the Brain Fuck Scheduler (BFS) is overly simplistic for modern multi-core hardware, primarily due to its use of a single global runqueue, which leads to increased contention and performance degradation on systems with many cores. Early benchmarks indicated that BFS scalability diminishes significantly beyond 16 CPU cores, limiting its suitability for high-core-count environments. Additionally, BFS lacks integration with control groups (cgroups), a key feature for resource management in contemporary Linux deployments, as explicitly stated in its documentation. Within the community, BFS has been praised for enhancing responsiveness and interactivity on lower-spec machines but criticized for disregarding established principles in scheduler design, earning its provocative name by "throwing out everything we know is good" about modern implementations. This view, originating from in 2009, highlights its deliberate rejection of complexity for simplicity, which benefits single-user scenarios but falters in server or multi-user contexts. As of 2025, BFS remains an out-of-tree patchset and has never been integrated into the mainline . Patches were last available through the (CK) repository for kernels up to the 4.x series, with updates ceasing in 2016. As of 2025, BFS remains unmaintained in its original form, though elements persist in community kernels like . It continues to be referenced in recent guides as an alternative for low-latency desktop setups, though its maintenance has ceased. BFS's legacy lies in sparking discussions on the value of scheduler simplicity for desktop use cases, influencing later efforts to balance fairness and responsiveness. Users seeking similar low-latency benefits without custom patches have increasingly migrated to the Earliest Eligible Virtual Deadline First (EEVDF) scheduler, which became the mainline default starting with 6.6.

Successors

MuQSS Overview

The Multiple Queue Skiplist Scheduler (MuQSS), developed by , represents an evolutionary successor to the Brain Fuck Scheduler (BFS), with its first major stable release announced on October 29, 2016. This scheduler was designed to mitigate the scalability limitations of BFS on systems with increasing numbers of CPU cores, particularly for desktop and interactive workloads, while preserving the core simplicity that distinguished BFS from the more complex (CFS). At its core, MuQSS utilizes multiple per-CPU runqueues to enable efficient local scheduling, combined with a global skiplist structure that tracks runqueue states across all CPUs for load balancing. This architecture supports O(log n) for key operations such as insertion, deletion, and lookups, where n is the number of CPUs, thereby improving multi-core performance without introducing the overhead or intricacy of CFS's mechanisms. Like its predecessor BFS, MuQSS was maintained as an out-of-tree patchset rather than integrated into the mainline . Development continued through periodic releases aligned with stable kernel versions, culminating in version 0.208 for 5.11 in February 2021. Kolivas retired the project in August 2021, noting advancements in the mainline scheduler and a decline in community interest as contributing factors.

Key Differences from BFS

MuQSS introduces per-CPU runqueues, contrasting with BFS's single global runqueue that relied on linked lists for all tasks across the system. Each MuQSS runqueue employs an 8-level skiplist structure, enabling O(log n) insertion times and O(1) selection of the task with the earliest virtual deadline, which minimizes overhead compared to BFS's O(n) scanning of the entire queue. This design also facilitates O(k) selection across k active CPUs during load balancing, reducing the need for global synchronization. In terms of , MuQSS addresses BFS's limitations on systems with more than 16 cores, where the global lock in BFS caused significant contention and performance degradation. By using fine-grained locking and local per-CPU queues, MuQSS scales effectively to 32 or more cores through reduced lock contention and NUMA-aware scheduling that leverages coherency without complex heuristics. Load balancing in MuQSS occurs opportunistically via trylock mechanisms, further enhancing throughput on multi-core while preserving low-latency behavior. MuQSS retains the core earliest-effective-virtual-deadline-first (EEVDF) from BFS for fair scheduling based on virtual deadlines but refines it with improved handling of deadlines using nanosecond-precision "niffies" instead of jiffies. It integrates real-time-like isolation directly into the normal scheduling class via SCHED_ISO, eliminating the need for separate cpu-isolation caps present in earlier BFS variants, while adding SCHED_IDLEPRIO for background tasks that only run on CPUs. These adjustments maintain BFS's tiered approach but streamline enforcement for better desktop responsiveness without additional tuning. Efficiency-wise, MuQSS remains significantly simpler than the mainline CFS, with a that avoids complex fairness accounting and group scheduling, though it incorporates modest additions for multi-queue support. It effectively handles up to 64 cores in practice, supporting up to 256 tasks per CPU via its skiplist , which also enables tickless for lower power consumption. Ultimately, MuQSS's development became redundant following the adoption of an EEVDF-based scheduler in the mainline in , which incorporated similar multi-queue and latency-focused ideas for improved interactivity.

References

  1. [1]
    The BFS FAQ
    BFS is the Brain Fuck Scheduler. It was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware. ie it ...
  2. [2]
    Completely fair Scheduler (CFS) and Brain Fuck Scheduler (BFS)
    Jul 12, 2025 · Brain Fuck Scheduler (BFS) : Unlike the CFS scheduler, BFS is O(n) scheduler which uses doubly linked list which is treated like a queue. So ...
  3. [3]
    Schedulers: the plot thickens - LWN.net
    Apr 17, 2007 · The RSDL scheduler (since renamed the staircase deadline scheduler) by Con Kolivas was, for a period of time, assumed to be positioned for ...
  4. [4]
    Ingo Molnar: BFS vs. mainline scheduler benchmarks and ... - LKML
    Sep 6, 2009 · hi Con, I've read your BFS announcement/FAQ with great interest: http://ck.kolivas.org/patches/bfs/bfs-faq.txt. First and foremost, let me ...
  5. [5]
    Two Years With Linux BFS, The Brain Fuck Scheduler - Phoronix
    Aug 16, 2011 · When Con Kolivas announced the Brain Fuck Scheduler (BFS) as an alternative to the Completely Fair Scheduler (CFS) that is the default scheduler ...Missing: date | Show results with:date
  6. [6]
    BFS Updated For Linux 4.8, To Be Succeeded By New MuQSS ...
    Oct 4, 2016 · Con Kolivas has rolled out the BFS scheduler v0.512 release for Linux 4.8, which may be his last "BFS" release as he's getting ready to ...
  7. [7]
    Con Kolivas: BFS cpu scheduler and skip list implementation - LKML
    Sep 24, 2011 · Hi all. Many of you may know about Skip lists as an alternative to balanced binary search trees. They feature O(log n) insertion, ...Missing: announcement | Show results with:announcement
  8. [8]
    Matthias Kohler: [ANNOUNCE] Multiple run-queues for BFS - LKML
    Dec 15, 2012 · I'm doing a CPU-Scheduler based on BFS by Con Kolivas with support for multiple run-queues. BFS in itself uses only one run-queue for all
  9. [9]
    bfs-v447-for-3.15.patch - GitHub Gist
    +BFS - The Brain Fuck Scheduler by Con Kolivas. +. +Goals. +. +The goal of the Brain Fuck Scheduler, referred to as BFS from here on, is to. +completely do ...
  10. [10]
  11. [11]
    The MuQSS CPU scheduler - LWN.net
    Apr 20, 2017 · First released in 2009, BFS was a simplified scheduler that was made in response to Kolivas's issues with the mainline scheduler for desktop use ...Missing: date | Show results with:date
  12. [12]
    [PDF] CFS, BFS, MuQSS, sched_ext, EEVDF
    Jun 2, 2023 · The task put into the queue receives a time quantum of rr_interval and deadline jiffies + (prio_ratio * rr_interval) where prio_ratio, like the ...
  13. [13]
    BFS | ck kernel wiki - Fandom
    The goal of the Brain Fuck Scheduler, referred to as BFS from here on, is to completely do away with the complex designs of the past for the cpu process
  14. [14]
    [PDF] BFS vs. CFS Scheduler Comparison - UNM CS
    Dec 11, 2009 · The Brain Fuck Scheduler (BFS) was written by Con Kolivas as an alternative to the CFS scheduler. Although it is not in the mainline Linux ...<|control11|><|separator|>
  15. [15]
    BFS cpu scheduler v0.304 stable release
    ### Summary of Con Kolivas' BFS Announcement on Realtime Policy, SCHED_FIFO, Prioritization, and Behavior for Realtime Tasks
  16. [16]
    http://ck.kolivas.org/patches/bfs/4.0/4.7/Incremen...
    ... virtual deadline first design, loosely based on EEVDF (earliest eligible virtual -deadline first) and my previous Staircase Deadline scheduler. Each ...<|separator|>
  17. [17]
  18. [18]
    BFS cpu scheduler and skip list implementation - LWN.net
    Sep 24, 2011 · ... of a custom version of skip lists for BFS in place of the O(n) lookup. The insertion remains O(log n), but by sorting all tasks realtime ...
  19. [19]
    BFS CPU scheduler v0.502 for linux-4.7 with skip list. - LWN.net
    Sep 23, 2016 · BFS CPU scheduler v0.502 for linux-4.7 with skip list. From: Con Kolivas <kernel-AT-kolivas.org>. To: linux-kernel-AT-vger.kernel.org. Subject ...
  20. [20]
    schedtool - query and set CPU scheduling parameters
    schedtool can set all CPU scheduling parameters Linux is capable of or display information for given processes. Long-running, non-interactive tasks may ...
  21. [21]
    freequaos/schedtool: query and set CPU scheduling ... - GitHub
    schedtool is the definitive interface to Linux's scheduler. It can be used to avoid skipping for A/V-applications, to lock processes onto certain CPUs on SMP/ ...
  22. [22]
    BFS Scheduler Updated For The Linux 4.3 Kernel - Phoronix
    Nov 15, 2015 · The Brain Fuck Scheduler v0.465 by Con Kolivas. A single shared ... Includes accurate sub-tick accounting of tasks so userspace ...
  23. [23]
    Debian -- Details of package schedtool in sid
    Queries/alters process' scheduling policy and CPU affinity. Schedtool can query or alter a process' scheduling policy in Linux, specifically assigning ...
  24. [24]
    schedtool 1.3.0-8 (x86_64) - Arch Linux
    Architecture: x86_64. Repository: Extra. Description: Query or alter a process' scheduling policy. Upstream URL: https://github.com/freequaos/schedtool.Missing: man | Show results with:man
  25. [25]
    Sabayon - DistroWatch.com
    May 17, 2025 · Sabayon Summary. Distribution, Sabayon (formerly Sabayon Linux, before that RR4 Linux and RR64 Linux) ... • schedtool-1.2.9 • scim-1.4.7
  26. [26]
    BFS Scheduler Benchmarks - Phoronix
    Sep 14, 2009 · The BFS scheduler is designed to offer "extremely low latencies for excellent interactivity", according to Con Kolivas. In this article we have ...
  27. [27]
    BFS Two Year Benchmarks - OpenBenchmarking.org
    Brain Fuck Scheduler benchmarks by Phoronix.com compared to the Completely Fair Scheduler on Linux 3.0 kernel. Compare your own system(s) to this ...
  28. [28]
    Relearning Linux Task Scheduling 6: CFS Is Not a Silver Bullet
    Apr 21, 2025 · Some developers tested BFS in desktop scenarios and found it performed much better than CFS. However, due to philosophical differences, BFS was ...
  29. [29]
    Zenwalk Continues Banging The BFS Scheduler - Phoronix
    Oct 15, 2012 · Zenwalk has been shipping the Brain Fuck Scheduler since 2010 as its default kernel scheduler ... scheduler include PCLinuxOS and Sabayon Linux.
  30. [30]
    Spotlight on Linux: PCLinuxOS 2010
    May 11, 2010 · By using the BFS, PCLOS is reported to perform faster than ever. BFS is a low latency desktop scheduler designed for high performance.Missing: adoption | Show results with:adoption
  31. [31]
    About GalliumOS
    Mar 4, 2016 · Alternative kernel schedulers to prevent system stalls. BFS for process scheduling; BFQ for I/O scheduling. Removed some services to improve ...
  32. [32]
    Brain Fuck Scheduler - Wikipedia
    Not to be confused with Brainfuck. ... The Brain Fuck Scheduler (BFS) is a process scheduler designed for the Linux kernel in August 2009 based on earliest ...Theoretical design and efficiency · Scheduling policies · Preemption · Benchmarks
  33. [33]
    Two Years With Linux BFS, The Brain Fuck Scheduler - Reddit
    Oct 13, 2011 · TIL of a process scheduler for the Linux kernel called the "Brain Fuck Scheduler." The creator, Con Kolivas, aptly named it so because he ...TIL of a process scheduler for the Linux kernel called the "Brain Fuck ...BFS (Brain Fuck Scheduler) for 3.12 released : r/linux - RedditMore results from www.reddit.com
  34. [34]
    Ingo Molnar Tests New BF Scheduler - » Linux Magazine
    Sep 8, 2009 · For example popular firmware OpenWRT shows significant better network performance with BFS, very popular Cyanogen custom Android firmware (which ...
  35. [35]
    how to improve user performance on android phones - nenolod.net
    Jun 28, 2010 · What about BFS you say? Well BFS does not appear to perform very well on Android, and Android's legitimate use of cgroups does not work on BFS.
  36. [36]
    BFS vs. CFS Scheduling in Linux - DEV Community
    Jul 24, 2025 · Two prominent schedulers in its history are the Brain Fuck Scheduler (BFS) and the Completely Fair Scheduler (CFS). BFS, developed by Con ...Missing: timeline | Show results with:timeline
  37. [37]
    Con Kolivas Contemplates Ending Kernel Development, Retiring ...
    Aug 31, 2021 · He shared today that he's thinking of ending his -ck / MuQSS effort so for now at least no updates are planned past the existing Linux 5.12 ...
  38. [38]
    EEVDF Scheduler Merged For Linux 6.6, Intel Hybrid Cluster ...
    Aug 29, 2023 · The EEVDF scheduler code has been merged for the in-development Linux 6.6 kernel. EEVDF replaces the existing CFS scheduler code.Missing: mainline | Show results with:mainline
  39. [39]
    [ANNOUNCE] Multiple Queue Skiplist Scheduler version 0.120
    Oct 29, 2016 · This is to announce the first major ~stable public release of MuQSS (pronounced mux), the Multiple Queue Skiplist Scheduler.<|control11|><|separator|>
  40. [40]
    MuQSS CPU Scheduler Released For Linux 4.9 - Phoronix
    Dec 11, 2016 · MuQSS v0.15 is an upgraded, stable version of the Multiple Queue Skiplist scheduler. This nearly 10,000 lines of code CPU scheduler continues to ...Missing: skip introduction date
  41. [41]
    Linux 5.11-ck1 Released With MuQSS 0.208 Scheduler - Phoronix
    Feb 18, 2021 · Linux 5.11-ck1 Released With MuQSS 0.208 Scheduler. Written by Michael Larabel in Linux Kernel on 18 February 2021 at 06:03 AM EST. Add A ...
  42. [42]
    MuQSS
    Oct 29, 2016 · MuQSS is a per-cpu runqueue variant of the original BFS scheduler with one 8 level skiplist per runqueue, and fine grained locking for much more ...
  43. [43]
    EEVDF & the mainline linux kernel scheduler
    ### Summary: Why MuQSS is Redundant Due to EEVDF in Mainline Kernel