<div dir="ltr">Sure, CFS does not have any deadlines at all. But I am trying to measure its performance w.r.t to some workloads having some periods and deadlines. So in that case will the tasks having deadline of < 2.5 ms always miss the deadline ?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 11, 2017 at 5:57 PM, Rik van Riel <span dir="ltr"><<a href="mailto:riel@surriel.com" target="_blank">riel@surriel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 2017-06-11 at 11:15 +0530, Rohith R wrote:<br>
> Hi,<br>
><br>
> I was working on the Linux CFS scheduler and came across this<br>
> tuneable parameter called `sched_wakeup_granularity_ns`. The use of<br>
> this goes as follows as described in [this paper](<a href="http://rouskas.csc" rel="noreferrer" target="_blank">http://rouskas.csc</a>.<br>
> <a href="http://ncsu.edu/Publications/Conferences/ICC-SPS-2015.pdf" rel="noreferrer" target="_blank">ncsu.edu/Publications/<wbr>Conferences/ICC-SPS-2015.pdf</a>).<br>
><br>
> > This parameter controls the wake-up latency of a task, i.e., the<br>
> amount of time it must lapse before it can preempt the current task.<br>
><br>
> Further looking up on this parameter from [here](<a href="https://www.systutor" rel="noreferrer" target="_blank">https://www.systutor</a><br>
> <a href="http://ials.com/239998/sched_min_granularity_ns-sched_latency_ns-cfs-affect-" rel="noreferrer" target="_blank">ials.com/239998/sched_min_<wbr>granularity_ns-sched_latency_<wbr>ns-cfs-affect-</a><br>
> timeslice-processes/) :<br>
><br>
> > If the difference between the virtual run time of current running<br>
> process and the virtual run time of preempting process is bigger than<br>
> the virtual run time of sched_wakeup_granularity_ns (here, transfer<br>
> sched_wakeup_granularity_ns to a virtual run time with preempting<br>
> process’s weight), the preemption happens.<br>
><br>
> The default value of this in my system is 2.5 milli seconds.<br>
><br>
> My question : If a process with a deadline <= 2.5 ms comes at time<br>
> another low priority process is executing then, it won't get its<br>
> chance to execute because of this minimum granularity and will always<br>
> miss its deadline.<br>
><br>
> Am I right in my claim ? Why is the Linux kernel designed like that ?<br>
<br>
</span>CFS does not have deadlines at all. You may be<br>
confusing the CFS scheduler and the deadline scheduler.<br>
<br>
The wakeup granularity in CFS is used to determine<br>
whether or not the scheduler should bother preempting<br>
the currently running task if a higher priority task<br>
becomes runnable.<br>
<br>
If the remaining amount of time in the currently running<br>
task's time slice is small, we are better off letting<br>
it run until the end of its time slice, before scheduling<br>
in the newly woken task.<br>
<span class=""><br>
> Of course we can set this parameter to 0 ms and re-compile the<br>
> kernel, but don't tasks with deadlines of 2.5 ms occur frequently in<br>
> day to day life ? Video decoders, sound processing apps, and other<br>
> latency critical workloads ?<br>
<br>
</span>Why recompile the kernel, when you can tune the value<br>
through /proc/sys/kernel/sched_wakeup_<wbr>granularity_ns ?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
All Rights Reversed.</font></span></blockquote></div><br></div>