<div dir="ltr"><span style="font-size:12.800000190734863px">Hi,</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">I was working on the Linux CFS scheduler and came across this tuneable parameter called `sched_wakeup_granularity_ns`. The use of this goes as follows as described in [this paper](</span><a href="http://rouskas.csc.ncsu.edu/Publications/Conferences/ICC-SPS-2015.pdf" rel="noreferrer" target="_blank" style="font-size:12.800000190734863px">http://rouskas.csc.<wbr>ncsu.edu/Publications/<wbr>Conferences/ICC-SPS-2015.pdf</a><span style="font-size:12.800000190734863px">).</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">&gt; This parameter controls the wake-up latency of a task, i.e., the amount of time it must lapse before it can preempt the current task.</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">Further looking up on this parameter from [here](</span><a href="https://www.systutorials.com/239998/sched_min_granularity_ns-sched_latency_ns-cfs-affect-timeslice-processes/" rel="noreferrer" target="_blank" style="font-size:12.800000190734863px">https://www.<wbr>systutorials.com/239998/sched_<wbr>min_granularity_ns-sched_<wbr>latency_ns-cfs-affect-<wbr>timeslice-processes/</a><span style="font-size:12.800000190734863px">) :</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">&gt; If the difference between the virtual run time of current running process and the virtual run time of preempting process is bigger than the virtual run time of sched_wakeup_granularity_ns (here, transfer sched_wakeup_granularity_ns to a virtual run time with preempting process’s weight), the preemption happens.</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">The default value of this in my system is 2.5 milli seconds.</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">My question : If a process with a deadline &lt;= 2.5 ms comes at time another low priority process is executing then, it won&#39;t get its chance to execute because of this minimum granularity and will always miss its deadline.</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">Am I right in my claim ? Why is the Linux kernel designed like that ?</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">Of course we can set this parameter to 0 ms and re-compile the kernel, but don&#39;t tasks with deadlines of 2.5 ms occur frequently in day to day life ? Video decoders, sound processing apps, and other latency critical workloads ?</span><br><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">- RR</span></div></div>