Calculate process scheduling time slices under the Linux CFS scheduler.
Linux's Completely Fair Scheduler (CFS) doesn't use fixed time slices; instead every runnable task accrues virtual runtime (vruntime) at a rate inversely proportional to its weight (derived from nice value via the kernel's sched_prio_to_weight table, where nice 0 = weight 1024), and CFS always picks the runnable task with the lowest vruntime to run next — so a higher-weight (lower nice) task's vruntime grows more slowly, letting it run more often without ever using a literally longer time slice. The approximate time slice a task gets in one scheduling period is its weight's share of sched_latency_ns, floored by sched_min_granularity_ns so very high task counts don't shrink slices to unreasonably small durations.
Virtual runtime
vruntime = actual_runtime × (nice_0_weight / task_weight)
Approximate time slice
time_slice ≈ max(min_granularity, sched_latency × (task_weight / nice_0_weight) / runnable_tasks)
Fixed time slices scale poorly with varying numbers of runnable tasks and don't cleanly support proportional priority. CFS instead tracks each task's accumulated vruntime and always runs whichever runnable task has the least of it, which naturally gives higher-weight (lower nice) tasks more CPU time over time without needing per-task slice-length bookkeeping.
It increases the task's weight (nice -20 ≈ weight 88761 vs. nice 0's 1024), which makes its vruntime accrue roughly 87× slower per unit of real CPU time — so it stays at the front of the 'lowest vruntime runs next' queue far more often, effectively getting far more CPU share under contention.
It's a floor on how small a computed time slice can get. Without it, a system with hundreds of runnable tasks sharing sched_latency_ns could compute vanishingly small per-task slices, causing excessive context-switch overhead; the floor trades a bit of fairness/latency for reduced scheduling overhead under high task counts.