Optimization and Best Practices

One advantage of EEVDF's design is that it reduces the need for manual tuning. In the CFS era, performance tweaking sometimes meant adjusting /proc/sys/kernel/sched_* knobs or altering scheduler behavior for specific scenarios (for example, increasing sched_wakeup_granularity_ns to reduce task-switch frequency on throughput-oriented servers or lowering it for desktops to improve interactivity). With EEVDF, many of those knobs either no longer exist or have a diminished role. The scheduler self-adjusts based on the lag/deadline algorithm.

Leverage Nice Levels and cgroups

These remain the primary tools for influencing CPU allocation. If you have batch jobs or background services (e.g., data indexing, backups) alongside latency-sensitive services (web servers, interactive SSH sessions, etc.), continue to use Unix priority (nice values or cgroup CPU shares) to give the background tasks a higher nice (lower priority) so that they yield CPU when other work is present. EEVDF will enforce fairness but with the weights you specify.

Understand "Latency Nice"

The kernel allows adjusting a task's latency requirement via the sched_setattr() system call. By default, the kernel assigns latency-nice values internally. In most cases you won't need to touch this. But if you develop or deploy software that is extremely latency-critical (for example, a soft real-time control system or a high-frequency trading engine) and cannot run as real-time process, you might explore the sched_setattr API to give it a lower latency_tolerance. This effectively tells EEVDF to give it shorter time slices.