Windows and Linux represent two fundamentally different approaches to CPU scheduling. Windows uses a strict priority-based preemptive scheduler where higher-priority threads always run before lower-priority threads. Linux employs the Completely Fair Scheduler (CFS), designed around the principle that CPU time should be divided fairly among all tasks based on their relative weights.

These aren't just implementation details—they reflect different design philosophies. Windows prioritizes deterministic responsiveness: the foreground application will always be responsive, system services will always handle critical events, and priority guarantees are honored strictly. Linux prioritizes fair sharing: every process deserves CPU time proportional to its importance, and no single task should monopolize the system regardless of its priority.

Neither approach is universally superior. Each excels in different scenarios, and understanding both helps you design systems that work well on either platform—or choose the right platform for specific workloads.

Windows: Priority-Based Preemptive Scheduling

Windows maintains a set of 32 priority levels (0-31). At any moment, the scheduler runs the highest-priority runnable thread. Key characteristics:

• Strict priority ordering: Priority 10 always runs before priority 9
• Round-robin within priority: Equal-priority threads share time via quantum
• Preemption on priority change: If a higher-priority thread becomes runnable, the current thread is immediately preempted
• Priority boosting: Dynamic adjustments for responsiveness (I/O completion, foreground, starvation)

Linux: Completely Fair Scheduler (CFS)

CFS models an "ideal" processor that could run all tasks simultaneously, each receiving 1/n of the CPU. Since real CPUs can only run one task per core, CFS simulates this by tracking how much each task has run and scheduling the task that has run the least. Key characteristics:

• Virtual runtime tracking: Each task accumulates "virtual runtime" (vruntime)
• Red-black tree organization: Tasks sorted by vruntime in a self-balancing tree
• Weighted fairness: Nice values adjust the rate of vruntime accumulation
• No fixed time slices: Run until a task with lower vruntime exists

Both systems provide mechanisms for adjusting task importance, but they work very differently.

Windows Priority System:

• 32 priority levels (0-31)
• Split into dynamic (1-15) and real-time (16-31) ranges
• Priority determines absolute scheduling order
• Higher priority = always run first
• Applications set priority via SetPriorityClass + SetThreadPriority

Linux Nice Values:

• Nice range: -20 (highest priority) to +19 (lowest priority)
• Default nice value is 0
• Nice affects weight in CFS calculations
• Higher weight = accumulate vruntime slower = run more often
• Nice doesn't guarantee running first—it influences CPU time share

Key behavioral difference:

Scenario: One high-priority task + one low-priority task, both CPU-bound

Windows behavior:
  High-priority task: ~100% CPU
  Low-priority task: ~0% CPU (runs only during boosts)
  
Linux CFS behavior:
  Nice -10 task: ~75% CPU (proportional to weight ratio)
  Nice +10 task: ~25% CPU

This is the fundamental difference: Windows gives absolute precedence to higher priority; Linux divides CPU proportionally based on weights.

Practical implications:

CFS's fairness model centers on virtual runtime (vruntime)—a key concept that has no equivalent in Windows.

How vruntime works:

Each task has a vruntime value representing how much "virtual" CPU time it has consumed. When a task runs:

vruntime += actual_runtime × (NICE_0_WEIGHT / task_weight)

• Nice 0 tasks: vruntime increases 1:1 with wall-clock time
• Nice -10 tasks (higher weight): vruntime increases slower
• Nice +10 tasks (lower weight): vruntime increases faster

CFS always runs the task with the lowest vruntime. This ensures that:

1. Tasks that have run less get to run more
2. Higher-weight tasks accumulate vruntime slower, so they run more often
3. Over time, all tasks' vruntime values converge (proportional CPU sharing)

The red-black tree:

CFS maintains runnable tasks in a red-black tree, sorted by vruntime:

                    [vrt=500]
                   /         \
            [vrt=300]       [vrt=700]
            /       \       /       \
       [vrt=200] [vrt=400] [vrt=600] [vrt=800]
            ^
            └── Leftmost node = next to run

• Selecting next task: O(1) - cached leftmost node
• Inserting/removing: O(log n) - tree rebalancing
• No priority queues: A single unified structure

min_vruntime tracking:

CFS tracks the minimum vruntime in the tree. When a task wakes from sleep:

new_task_vruntime = max(wake_vruntime, cfs_rq->min_vruntime - sched_latency)

This prevents sleeping tasks from being starved (they don't wake with vruntime = 0 and hog the CPU) while still giving them a slight advantage for responsiveness.

Both Windows and Linux provide real-time scheduling policies for time-critical applications, but with different approaches.

Windows Real-Time:

• REALTIME_PRIORITY_CLASS: Access to priorities 16-31
• No boosting: Real-time threads never receive priority boosts
• Strict preemption: Real-time threads always preempt dynamic threads
• Kernel integration: System threads, drivers run at real-time priorities
• Risk: Runaway real-time thread can freeze the system

Linux Real-Time Policies:

Linux provides multiple real-time scheduling policies via POSIX:

• SCHED_FIFO: First-in-first-out at each priority; runs until yielding
• SCHED_RR: Round-robin at each priority; time slice rotates between equal-priority tasks
• SCHED_DEADLINE: Earliest Deadline First (EDF) scheduler (Linux 3.14+)
• RT priority range: 1-99 (higher number = higher priority)

SCHED_DEADLINE: Linux's Advanced Real-Time Scheduler

SCHED_DEADLINE implements Earliest Deadline First (EDF) scheduling with Constant Bandwidth Server (CBS). Each task specifies:

• runtime: CPU time needed per period
• deadline: When the work must complete
• period: How often the task runs

struct sched_attr attr = {
    .size = sizeof(attr),
    .sched_policy = SCHED_DEADLINE,
    .sched_runtime = 10 * 1000 * 1000,    // 10 ms
    .sched_deadline = 30 * 1000 * 1000,   // 30 ms
    .sched_period = 30 * 1000 * 1000,     // 30 ms period
};
sched_setattr(0, &attr, 0);

The kernel performs admission control: if accepting a new SCHED_DEADLINE task would make existing deadlines unachievable, the request is rejected. This provides stronger guarantees than priority-only scheduling.

Both operating systems have evolved sophisticated multiprocessor scheduling, but with different approaches to load balancing and processor affinity.

Windows Multiprocessor Scheduling:

• Symmetric multiprocessing (SMP): All processors are equivalent
• Processor affinity: Threads prefer their last-run processor (cache warmth)
• Soft affinity: Scheduler tries to maintain affinity but will migrate for load balance
• Hard affinity: Applications can restrict threads to specific processors
• NUMA awareness: Scheduler considers memory locality on NUMA systems
• Per-processor ready queues: Each processor has its own queue, reducing lock contention

Linux Multiprocessor Scheduling:

• Per-CPU run queues: Each CPU has its own CFS tree
• Load balancing domains: Hierarchical balancing (SMT → Core → Socket → Node)
• NUMA balancing: Automatic memory migration to follow processes
• cgroup awareness: Fair scheduling across containers/cgroups
• Energy-aware scheduling: Consider power efficiency on heterogeneous systems (big.LITTLE)

*Hybrid CPUs (Intel 12th Gen+, ARM big.LITTLE) have performance and efficiency cores.

Heterogeneous scheduling (modern focus):

With Intel's hybrid architecture (P-cores and E-cores) and ARM's big.LITTLE, both operating systems now must decide which core type to use:

Windows Thread Director:

• Intel-provided driver that communicates thread characteristics to scheduler
• Monitors instruction mix, IPC to classify threads
• Steers performance-sensitive threads to P-cores
• Background work directed to E-cores

Linux Energy Aware Scheduling (EAS):

• Uses CPU energy model (from device tree or ACPI)
• Considers energy cost of each placement
• Balances performance vs. power consumption
• Works with CPUFreq for coordinated DVFS

For interactive and real-time workloads, scheduling latency—the time between a task becoming runnable and actually running—is critical.

Windows Latency Characteristics:

• Deterministic for priority differences: Higher-priority thread runs immediately upon becoming ready
• Foreground boost: Active application gets priority and quantum advantages
• Timer resolution: Default 15.625 ms, reducible to ~1 ms via timeBeginPeriod
• DPC/ISR: Deferred Procedure Calls and Interrupt Service Routines have even higher priority than realtime threads
• Typical latency: ~1-15 ms for Normal priority, <1ms at higher priorities

Linux Latency Characteristics:

• CFS target latency: sched_latency_ns controls how often tasks get CPU (typically 6-24 ms)
• Minimum granularity: sched_min_granularity_ns prevents too-short time slices (typically 0.75-3 ms)
• Wake-up preemption: Waking task may preempt current if vruntime is sufficiently lower
• PREEMPT_RT patch: Real-time kernel adds deterministic preemption
• Typical latency: ~3-20 ms for SCHED_OTHER, <100 µs for SCHED_FIFO

Linux CFS Tuning for Latency:

CFS has tunable parameters in /proc/sys/kernel/:

# Lower latency (more frequent switching, worse throughput)
echo 1000000 > /proc/sys/kernel/sched_latency_ns      # 1 ms target
echo 500000 > /proc/sys/kernel/sched_min_granularity_ns

# Higher throughput (less switching, worse latency)
echo 18000000 > /proc/sys/kernel/sched_latency_ns     # 18 ms target
echo 2250000 > /proc/sys/kernel/sched_min_granularity_ns

The PREEMPT_RT Patch:

For hard real-time requirements, Linux offers the PREEMPT_RT patch set (being mainlined progressively):

• Makes almost all kernel code preemptible
• Converts spinlocks to sleeping mutexes
• Threaded interrupt handlers
• Priority inheritance for mutexes
• Enables sub-100 µs worst-case latency

How do these scheduling differences affect real-world performance? Let's examine different workload categories:

Interactive Desktop Workloads:

Server Workloads:

Real-Time/Low-Latency:

The differences between Windows and Linux scheduling reflect deeper philosophical choices about what an operating system should optimize for.

Neither is "better"—they're optimized for different goals:

• Windows excels when one interactive user's experience matters most
• Linux excels when fair resource sharing among many tasks matters most

Convergence trends:

Both systems are evolving toward each other in some ways:

• Windows added more fairness mechanisms (starvation prevention, quantum accounting)
• Linux added more interactivity features (EEVDF scheduler replacing CFS, latency-nice)

Recent Linux development (EEVDF - Earliest Eligible Virtual Deadline First) attempts to bring more deterministic latency guarantees while maintaining fairness—a recognition that pure fairness isn't always optimal.

Choosing the right platform:

For new projects:

We've comprehensively compared Windows and Linux scheduling, revealing two distinct approaches to the fundamental problem of allocating CPU time among competing tasks.

Module complete:

You've now mastered Windows scheduling: priority classes establish process-level importance, priority levels provide per-thread control, priority boosting maintains responsiveness, quantum management allocates time slices, and this comparison with Linux provides crucial perspective on the design space of CPU schedulers.

This knowledge enables you to:

• Design applications that behave well under both operating systems
• Diagnose scheduling-related performance problems
• Choose appropriate priority settings for different workloads
• Understand why the same application may behave differently on Windows vs. Linux
• Make informed platform choices for new projects