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 ? On Sun, Jun 11, 2017 at 5:57 PM, Rik van Riel <riel@surriel.com> wrote:
On Sun, 2017-06-11 at 11:15 +0530, Rohith R wrote:
Hi,
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](http://rouskas.csc. ncsu.edu/Publications/Conferences/ICC-SPS-2015.pdf).
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.
Further looking up on this parameter from [here](https://www.systutor ials.com/239998/sched_min_granularity_ns-sched_latency_ns-cfs-affect- timeslice-processes/) :
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.
The default value of this in my system is 2.5 milli seconds.
My question : If a process with a deadline <= 2.5 ms comes at time another low priority process is executing then, it won't get its chance to execute because of this minimum granularity and will always miss its deadline.
Am I right in my claim ? Why is the Linux kernel designed like that ?
CFS does not have deadlines at all. You may be confusing the CFS scheduler and the deadline scheduler.
The wakeup granularity in CFS is used to determine whether or not the scheduler should bother preempting the currently running task if a higher priority task becomes runnable.
If the remaining amount of time in the currently running task's time slice is small, we are better off letting it run until the end of its time slice, before scheduling in the newly woken task.
Of course we can set this parameter to 0 ms and re-compile the kernel, but don'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 ?
Why recompile the kernel, when you can tune the value through /proc/sys/kernel/sched_wakeup_granularity_ns ?
-- All Rights Reversed.